Method and system for role binding and content pushing of people and stores based on NFC and two-dimensional code

Abstract

The application relates to a store role binding and content pushing method and system based on NFC and a two-dimensional code, and belongs to the technical field of data processing and information pushing. The method comprises the following steps: extracting a touch point identifier and a touch point type in a client NFC and two-dimensional code dual-mode access request message, and generating a unified touch point data object; taking the touch point identifier as an index to position a target store, executing store touch point binding modeling, and generating a store touch point binding data set; obtaining a user identity identifier, executing store touch point binding data set store role strategy pool matching, determining a corresponding role identifier of the user, and constructing a user-store role association object; executing multi-level assembly of a scene-based pushing configuration on the user-store role association object, and generating a pushing configuration parameter set; encapsulating a content distribution message and delivering the content distribution message to a client, and triggering the client to execute role-based content rendering. The application realizes role-based and differentiated content pushing, and improves content matching precision and pushing conversion efficiency.

Description

Technical Field

[0001] This invention belongs to the field of data processing and information push technology, specifically relating to a method and system for binding store and human roles and pushing content based on NFC and QR codes. Background Technology

[0002] In industries such as catering (restaurant kitchens) and the automotive aftermarket (auto repair shops), product brands (e.g., seasoning ingredient suppliers, auto parts and maintenance product manufacturers) generally face the problem of low efficiency in reaching end-user channels. There are multiple intermediaries between brands and key decision-makers in end-user stores—restaurant chefs and auto mechanics—including distributors and store owners, lacking a direct and sustainable digital connection. In recent years, "one item, one code" technology has been applied to some extent in product anti-counterfeiting and consumer QR code promotions. However, existing technologies still have significant shortcomings in reaching and building relationships with professional roles such as chefs and mechanics.

[0003] Existing "one product, one code" marketing solutions primarily target end consumers for anti-counterfeiting verification or promotional lotteries. Their core logic is "consumer scans code—brand obtains consumer information—general content is pushed," without establishing differentiated content distribution mechanisms for different professional roles. Specifically: First, the terminal reach chain is long. Brands lack technical solutions to directly transform offline physical touchpoints into "people-store" relationship binding entry points. Traditional one-way reach methods relying on verbal promotion by sales personnel and SMS notifications are inefficient and have poor retention, failing to achieve "one-time binding, long-term activity." Second, core decision-making groups (mechanics, chefs) lack convenient and efficient entry points for sustained activity. Traditional in-store displays fail to stimulate their active participation, resulting in low brand loyalty. Third, the deployment of physical touchpoints in stores heavily relies on sales personnel visiting the stores. Each store requires on-site scanning and binding of store files and geofencing. When brands need to distribute products in hundreds or even thousands of stores, personnel costs rise sharply, deployment cycles are long, and cross-regional collaboration is difficult.

[0004] At the interaction level, some solutions only support QR code scanning, requiring users to open the camera, focus, and recognize the code, resulting in a lengthy operation process. Other solutions only support NFC tap-to-pay, but older Android phones and iOS systems have NFC functionality limitations, leading to limited coverage due to the single-entry mode. While some solutions attempt to integrate NFC and QR codes onto the same platform, they fail to address the data normalization issue between the two interaction methods—NFC chip IDs and QR code values ​​belong to different physical world data formats, and existing solutions lack the technical means to unify them into a single data structure. Furthermore, existing systems lack the ability to accurately collect and record key personnel's check-in, training, repeat purchases, and repeat scans, and lack a closed-loop mechanism for reward distribution and private domain accumulation, making it difficult to assess and quantify marketing ROI.

[0005] In summary, existing technologies lack a systematic solution to transform offline physical touchpoints into "people-store relationship binding entry points" with a single click, lack differentiated content distribution mechanisms for professional roles, lack technical means for the dual-mode fusion of NFC and QR codes and data normalization processing, and also lack a closed-loop operation system based on the "people-store-role" ternary relationship model. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, this invention provides a method and system for binding store / person roles and pushing content based on NFC and QR codes. The objective of this invention can be achieved through the following technical solutions: Extract the touch point identifier and touch point type fields from the client's NFC and QR code dual-mode access request messages to generate a unified touch point data object; Store files are retrieved using touchpoint identifiers as indexes, store identifiers and store attribute information are extracted, store touchpoint binding modeling is performed on the touchpoint identifiers and store information, store touchpoint binding objects are generated, and the data is aggregated to form a store touchpoint binding dataset. Obtain the user identity identifier of the accessing user, perform store role policy pool matching on the store touchpoint binding dataset, and perform role attribution inference on the user identity identifier to construct user-store role association objects; Perform multi-level assembly of contextualized push configuration for user-store role association objects, and generate content push configuration parameters; The content push configuration parameters are encapsulated to generate a content distribution message carrying a role-differentiated tag, which triggers the client to perform role-based content rendering according to the display strategy corresponding to the role-differentiated tag.

[0007] Specifically, the NFC and QR code dual-mode access request includes both NFC access and QR code access: Receive access requests initiated by mobile terminals, parse the request type to determine the access method; When the access method is NFC, the contact identifier corresponding to the built-in chip of the physical contact is read. When the access method is QR code, the contact identifier carried by the QR code is parsed. The contact identifiers obtained by different access methods are uniformly converted into a format and combined with the contact type field to generate a unified contact data object.

[0008] Specifically, the process of modeling the store touchpoint binding includes: Read the touchpoint identifier from the unified touchpoint data object, retrieve the corresponding store profile information based on the touchpoint identifier; extract the store identifier, store location information, store type and store attribute information, establish an association mapping with the touchpoint identifier according to the preset field mapping rules, and generate the corresponding store touchpoint binding object, wherein the store touchpoint binding object is constructed through on-site deployment binding method and backend pre-binding activation method.

[0009] Specifically, the on-site deployment binding methods include: The system reads the touchpoint identifier corresponding to the physical touchpoint through the business terminal, enters the target store profile information and obtains the store location information; it then associates and binds the touchpoint identifier with the store identifier, submits the touchpoint identifier, store identifier and store location information to the platform server, generates the store touchpoint binding relationship, and updates the physical touchpoint binding status.

[0010] Specifically, the background pre-binding activation method includes: A pre-binding relationship between touchpoint identifiers and store identifiers is established in advance, and the physical touchpoints are configured to be in an activated state. The activation request submitted by the store terminal is obtained, and the consistency of the store identity information and store location information is verified. After the verification is passed, the physical touchpoint status is updated, and the corresponding store touchpoint binding relationship is generated.

[0011] Specifically, the process of matching the store role strategy pool includes: Read the store type information from the store touchpoint binding dataset, query the store role strategy pool using the store type as the retrieval index, and obtain a set of candidate role identifiers that match the current store type; push the set of candidate role identifiers to the accessing user, and determine the role identifier based on the target role identifier selected by the accessing user from the set of candidate role identifiers.

[0012] Specifically, the process of deducing the role attribution includes: Using the combination key consisting of user identity and store identity as the query condition, perform an attribution matching query in the preset identity-role mapping table to deduce the corresponding role identity; construct a user-store role association object based on the deduced role identity.

[0013] Specifically, the execution process of the multi-level assembly includes: The process involves four levels of content creation: First, the role identifier in the user-store role association object is used as the first level of content creation. A set of candidate content resources matching the current role is retrieved from a pre-defined content resource library. Second, the store identifier is used as the second level of content creation. Store affiliation filtering is applied to the candidate content resources, eliminating those irrelevant to the current store. Third, the current access time is used as the third level of content creation. Timeliness filtering is applied to the filtered content resources, retaining those that are valid and conform to the current season. Fourth, the user's historical interaction records are used as the fourth level of content creation. Priority is reordered for the filtered content resources, placing user-preferred content resources at the top. Finally, the content resources processed through these four levels are fused to generate scenario configuration parameters, which are temporarily stored in the extended fields of the user-store role association object. These parameters will be used to generate a push configuration parameter set when called in subsequent processes.

[0014] Specifically, the process of rendering the characterized content includes: The client receives and parses the role-differentiation tags embedded in the content distribution message, and matches the content display strategy corresponding to the current role locally based on the role-differentiation tags. According to the matched display strategy, the content data in the push configuration parameter set is rendered to the corresponding independent functional display areas. Each functional display area loads display content matching its own area type based on the push configuration parameter set, and the content is then combined and presented on the client interface. The independent functional display areas include a product introduction area, an activity information area, a training and learning area, a check-in and interaction area, and a scenario quick lookup area.

[0015] Specifically, the closed-loop processing of user interaction behavior after the characterized content is rendered: The client pre-establishes a standardized set of interactive behavior events, captures various interactive operations generated by users in the function display area in real time, and generates structured behavior event data based on the captured interactive operations. The structured behavior event data is reported to the platform server, which matches the event type and event parameters in the behavior event data with preset incentive rules and generates corresponding incentive data. The incentive data is written to the user's account and a complete interactive behavior log is stored synchronously, forming a complete closed-loop link from user operation to incentive feedback.

[0016] Specifically, a preliminary risk verification process is included before generating the corresponding incentive data: The platform server extracts the store location information, user terminal device characteristics, and access behavior information for the current period corresponding to this access. It performs electronic fence compliance verification on the store location information to determine whether the access is within the store's effective service range, performs device anomaly verification on the device characteristics to determine whether there is high-frequency access behavior from a single device, and performs access frequency threshold verification on the access behavior information for the time period to determine whether the number of accesses within a unit time period exceeds the normal range. The access risk judgment result is generated by combining the results of the three verifications. When any one verification fails, the platform server intercepts the generation of incentive data and records the abnormal access event.

[0017] Specifically, the NFC and QR code-based human-store role binding and content push system includes: The touch point parsing module is used to extract the touch point identifier and touch point type fields from the client's NFC and QR code dual-mode access request messages and generate a unified touch point data object. The store binding module uses touchpoint identifiers as indexes to locate target stores, establishes store touchpoint binding relationships corresponding to unified touchpoint data objects, and generates store touchpoint binding datasets. The role matching module is used to obtain the user identity identifier of the accessing user, perform store role policy pool matching on the store touchpoint binding dataset, and perform role attribution inference on the user identity identifier to build user-store role association objects; The content assembly module performs multi-level assembly of scenario-based push configurations for user-store role association objects, and generates a set of push configuration parameters; The push execution module encapsulates the push configuration parameter set into messages, generates a content distribution message carrying a role-differentiated tag, and triggers the client to execute role-based content rendering according to the display strategy corresponding to the role-differentiated tag.

[0018] The beneficial effects of this invention are as follows: (1) Unlike the existing "one item, one code" system where all users receive the same content after scanning the code, this invention constructs a store role strategy pool data structure based on store type. Each store type corresponds to multiple candidate role identifiers, and each role identifier is bound to an independent content template, display strategy, push rule, and incentive rule. This strategy pool uses store type as the first-level search index and role identifier as the second-level search index, supporting quick retrieval and extraction of the corresponding complete configuration parameters based on the user's store type and selected role. After the user completes store binding, the system retrieves matching content resources from the preset content resource library based on their role identifier, and sequentially filters through store affiliation, timeliness, and user historical behavior priority, achieving a four-level convergence of content from "full generalization" to "precise adaptation". Taking the catering scenario as an example, chefs can directly obtain recipe quick reference cards and cooking skill videos after scanning the code, while mechanics can directly obtain equipment maintenance manuals and construction specifications after scanning the code. This mechanism embeds content consumption into the user's actual workflow, improving the accuracy of content matching and user participation, enabling brands to carry out differentiated operation strategies for different professional roles.

[0019] (2) This invention integrates the NFC chip and QR code on the same physical carrier, allowing users to access the system via a "tap-to-click" method that redirects within milliseconds or by "scanning," ensuring full smartphone coverage. Simultaneously, a dual-mode data normalization mapping mechanism is established, shielding the system from underlying hardware differences for upper-layer services. The deployment phase provides a backend pre-binding activation mode, supporting batch pre-association by brand backends, logistics delivery, and store self-activation, completely eliminating reliance on on-site work hours for sales personnel and significantly reducing the labor costs and deployment cycle for large-scale distribution.

[0020] (3) This invention breaks through the traditional binary "person-store" binding and constructs a three-dimensional data model of "person-store-role", enabling brands to depict end-user profiles from three dimensions: user, store, and role. A standardized behavioral event collection and incentive closed-loop mechanism is established, and user behaviors such as check-in, learning, and re-scanning are traceable and rewards are quantifiable. Before incentives are issued, triple verification of electronic fences, device fingerprints, and access frequency is performed to ensure data authenticity and provide reliable support for marketing ROI evaluation and strategy iteration. Attached Figure Description

[0021] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart illustrating the method for binding store personnel and pushing content based on NFC and QR codes according to the present invention. Figure 2 This is a schematic diagram of the architecture of the NFC and QR code-based human-store role binding and content push method in this invention; Figure 3 This is a schematic diagram of the three-element relationship between people, shops, and roles in this invention. Detailed Implementation

[0023] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0024] Please see Figures 1-3 The method for binding store / person roles and pushing content based on NFC and QR codes includes the following steps: Step 1: Extract the touch point identifier and touch point type fields from the client's NFC and QR code dual-mode access request messages, and generate a unified touch point data object; In this embodiment, the user uses a mobile terminal to touch or scan the dual-mode physical touchpoints deployed in the store to trigger an access request.

[0025] The physical contact is a contactless sticker carrier integrating an NFC chip and a printed QR code. The NFC chip stores a unique identifier serial number written at the factory, conforming to the ISO / IEC 14443 Type A / B protocol. When an NFC reader (i.e., the user terminal) enters the chip's radio frequency field (at a distance of less than 4 cm), the chip returns the stored identifier data to the reader via load modulation. The QR code uses the QR Code encoding standard and carries a Uniform Resource Locator (URL) pre-configured by the brand. This URL path embeds query parameters, the values ​​of which are unique code values ​​pre-generated by the platform backend.

[0026] The client executes different reading logic based on the user's operation method: When a user brings the back of the device close to a physical contact point (NFC method), the device's operating system initiates a tag discovery scan via the NFC radio frequency interface. Taking the Android system as an example, the system registers foreground tag dispatching through the NfcAdapter.enableForegroundDispatch() method. When a tag with a TECH type of NfcA or NfcF is detected, the onNewIntent() method is called back. The client extracts the NDEF message record from the EXTRA_NDEF_MESSAGES of the Intent object and parses out the chip identification field.

[0027] When a user scans a QR code on a physical contact surface using the terminal's camera (QR code method), the terminal calls the camera's hardware interface to acquire image data and sends it to the decoder. The decoder sequentially performs image grayscale conversion (converting RGB pixels to brightness values ​​Y=0.299R+0.587G+0.114B), binarization (setting a threshold T, setting it to 255 if greater than T, and 0 if less than T), RS error correction code verification (Reed-Solomon error correction, correcting errors in no more than 7% of the total codewords), and symbol decoding (extracting data codewords according to the QR Code version format). Finally, it recovers the URL string from the data codewords and extracts the code value parameters from the query parameters.

[0028] The client encapsulates the obtained touch identifier (NFC chip ID or QR code value) and touch type marker (marking the current triggering method as NFC or QR) according to a predefined message structure and reports it to the platform server via the HTTPS protocol.

[0029] After receiving the message, the platform server first performs a message integrity check—verifying whether the difference between the timestamp field in the message and the server's current time is within a preset threshold (default 300 seconds). If the difference exceeds the threshold, the request is considered expired and discarded to prevent replay attacks. After successful verification, the platform server performs a unified data format conversion on the two types of touchpoint identifiers, generating a unified touchpoint data object. The data structure of this object includes the following fields: touchpoint_id: Normalized touchpoint identifier (converts NFC chip ID and QR code value into a fixed-length string format); access_type: Contact type (enumeration value: NFC or QR); access_time: Access timestamp; client_ip: Client IP address; This unified touchpoint data object serves as the basic data input for all subsequent processing flows, enabling the system to completely shield the differences in underlying interaction methods from the upper-level business logic.

[0030] Step 2: Retrieve store files using touchpoint identifiers as indexes, extract store identifiers and store attribute information, and perform store touchpoint binding modeling on the touchpoint identifiers and store information; In this embodiment, the platform server extracts the `touchpoint_id` field value from the unified touchpoint data object generated in step one, and uses it as the primary key to query the pre-built store touchpoint mapping records in the platform database. These store touchpoint mapping records have already been established during the store deployment phase. The database stores the correspondence between touchpoint identifiers and store profiles. Each record includes fields such as touchpoint identifier, store identifier, store name, store type, product category, store geographical coordinates (longitude, latitude), geofence radius (default 500 meters), binding status (value is pending activation or already effective), and binding time.

[0031] The platform executes database query statements: The query `SELECT * FROM touchpoint_store_mapping WHERE touchpoint_id = ? AND bind_status = 'Active'` retrieves the touchpoint ID and all store profile information from the result set if the query returns a non-empty result (meaning the touchpoint is already effectively bound to a store). If the query returns an empty result (meaning the touchpoint is not yet bound to any store), the subsequent process terminates and returns a "Touchpoint not bound" message.

[0032] Upon a successful match, the platform server generates a store touchpoint binding link record. This record includes fields such as touchpoint identifier, store identifier, binding effective time, and binding status, serving as persistent proof of the unique correspondence between the touchpoint and the store. When generating this record, the platform simultaneously associates it with store profile information—reading complete attribute data of the store from the store profile table (store name, store type, product category, geographical coordinates, geofence radius, contact person, and contact number) and writing it into the extended storage fields of the binding link, forming a single, complete store touchpoint binding relationship.

[0033] The platform repeats the mapping and association operations described above for all deployed physical touchpoints and their corresponding store profiles, compiling all store touchpoint binding relationship records into a single store touchpoint binding dataset. This dataset covers the mapping relationships between all stores and touchpoints in the system, supporting subsequent steps to retrieve, filter, and perform statistical queries on the dataset using store identifiers as the dimension.

[0034] In this embodiment, store touchpoint binding modeling is used to associate and organize touchpoint identifiers in a unified touchpoint data object with store information in the store profile. Touchpoint identifiers, store identifiers, store types, store location information, and store attribute information are integrated according to preset association rules to generate a store touchpoint binding object. Multiple store touchpoint binding objects are further aggregated to form a store touchpoint binding dataset. This store touchpoint binding modeling is a data organization and processing process oriented towards data objects, used to unify the association description between physical touchpoints and target stores, providing consistent data input for subsequent store role strategy pool matching and user-store role association object construction. This store touchpoint binding modeling is a data organization and processing process, not the establishment of a predictive or computational model.

[0035] The establishment of store touchpoint mapping records (i.e., the store deployment phase) includes the following two methods: (a) On-site deployment and binding method Sales personnel arrive at the target store with the physical touchpoints, and after affixing them, open the dedicated app on the sales terminal. After the app reads the touchpoint identifier, an information entry interface pops up, where the sales personnel enter the store name, store type (values ​​include restaurants, auto repair shops, etc.), product category, contact person, and contact number.

[0036] When a business user clicks submit, the app calls the location service interface provided by the terminal operating system (LocationManager for Android, CLLocationManager for iOS) to obtain the current GPS coordinates. The location service calculates the longitude and latitude of the terminal's current location using GPS satellite signals or network-assisted positioning (A-GPS), with an accuracy typically between 10 and 50 meters.

[0037] The app reports touchpoint identifiers, store profile information, and GPS coordinates to the platform server via an API interface. Upon receiving the data, the platform performs the following operations: First, it generates a globally unique store identifier (store_id) for the current store. Then, it creates a corresponding record between the touchpoint identifier and the store identifier in the store touchpoint mapping record, writes the GPS coordinates into the geographic coordinates field of the store profile, and simultaneously delineates a circular electronic fence with a radius of 500 meters centered on these coordinates. Finally, it marks the binding status field of the touchpoint as active, thus completing the deployment of the physical touchpoint and making it accessible to users.

[0038] (ii) Backend pre-binding activation method Brand operations staff perform batch import operations in the platform's management backend. They organize store profile data according to the platform's provided Excel or CSV templates—each row containing fields such as store name, store type, product category, affiliated distributor, and store registered address—and upload the organized data file to the platform. After reading the file, the platform calls the geocoding service interface to convert the store registered address string into geographic coordinates. The geocoding service works by segmenting the address string into a combination of administrative division, street, and house number, retrieving matching coordinates from the spatial database, and returning (longitude, latitude) values. Records where geocoding fails are marked as "coordinates to be supplemented" and await manual input by the operations staff.

[0039] Operations personnel select a batch of unbound physical touchpoints from the inventory touchpoint list in the "Touchpoint Management" interface in the backend. Through interface operations, they batch-match the selected touchpoint identifiers with target store identifiers and submit a pre-binding instruction. Upon receiving the instruction, the platform creates a pre-binding record for each pair of touchpoint identifiers and store identifiers in the store touchpoint mapping record, and uniformly marks the binding status field of each touchpoint as pending activation. This batch of physical touchpoints then completes the backend pre-association.

[0040] The brand will package the pre-bound physical touchpoints according to the stores and deliver them to the corresponding stores via logistics. After receiving the materials, store staff will affix them to the designated locations in the store, open the store's mini-program, select the "Activate Touchpoints" function, and enter the activation page by scanning the touchpoint identifier via NFC or QR code.

[0041] After receiving the activation request from the store, the platform performs two verifications: The first layer is account verification—determining whether the store identifier belonging to the store account currently logged in by the operator matches the store identifier in the pre-bound record for this touchpoint. This verification is achieved by comparing the store_id in the request parameters with the store_id in the pre-bound record in the database.

[0042] The second step is geolocation verification—calculating the distance between the GPS coordinates reported by the store and the coordinates of the pre-recorded store registration address. The distance calculation uses the Haversine formula: , Where d: the calculated great circle distance between the two points, in kilometers (km), is used to compare and determine the distance with a preset threshold (default 1 km); R: The average radius of the Earth, taken as 6371 km. This value is the approximate radius of the Earth recommended by the International Union of Geodesy and Geophysics (IUGG). φ1: The latitude value of the pre-recorded address of the store, in radians (rad). It is obtained by parsing the store's registered address through geocoding service, and then multiplying the decimal degree number (in degrees) by π / 180 to convert it into a radian value for use in trigonometric function calculations. φ2: GPS latitude value reported by the store terminal, in radians (rad), obtained by converting the decimal coordinates returned by the terminal positioning service; Δφ=φ2-φ1: The difference in latitude between two points, that is, the absolute value of the difference between the latitude reported by the terminal and the latitude pre-recorded by the store, in radians; λ1: Longitude value of the pre-recorded store address, in radians (rad), converted in the same way as latitude; λ2: GPS longitude value reported by the store terminal, in radians (rad); Δλ=λ2-λ1: The difference in longitude between two points, that is, the absolute value of the difference between the longitude reported by the terminal and the longitude pre-recorded by the store, in radians; arcsin: The arcsine function, the core calculation step of the Haversine formula, maps the square root result back to the angle value; sin²(·) represents the square of sin(·), i.e. (sin(·))², and is used for the calculation of the semi-versus in the Haversine formula; The platform compares the calculated distance d with the preset threshold T=1km to determine the location: if d≤T, the location verification passes and the store terminal is indeed located within 1km of the store's registered address; if d>T, the location verification fails, indicating that the location reported by the store terminal deviates too much from the actual location of the store, and the activation request may involve misplacement of touch points or fraudulent claims. The platform refuses activation and records the anomaly.

[0043] After both verifications pass, the platform updates the binding status field of the touchpoint from "Pending Activation" to "Activated," and the physical touchpoint is officially bound and accessible to users. If either verification fails, the platform rejects the activation request and returns an error message to prevent the touchpoint from being mistakenly affixed to other stores or fraudulently claimed.

[0044] Step 3: Obtain the user identity identifier of the accessing user, perform store role policy pool matching on the store touchpoint binding dataset, and perform role attribution inference on the user identity identifier to construct the user-store role association object; In this embodiment, after the user completes the triggered access in step one, the platform server enters the user identity authentication and role assignment stage.

[0045] The platform server first calls the identity authentication module to obtain the identity identifier of the currently accessing user. The authentication module supports multiple authentication sources and calls them in a chain according to priority: The preferred authentication source is a third-party identity authentication interface (taking WeChat Open Platform as an example). The client calls the WeChat login interface to obtain a temporary credential code. The platform server uses the code parameter to call the / sns / oauth2 / access_token endpoint of the WeChat interface server, passing in the AppID and AppSecret for identity verification. After verifying the validity of the credential, the WeChat server returns the user's unique identifier (openid field) under that application. The platform uses this openid value as the user's globally unique identifier.

[0046] When third-party authentication is unavailable (e.g., the user has not installed the WeChat client), the platform downgrades to SMS verification code authentication. The client prompts the user to enter their mobile phone number, and the platform calls the SMS gateway service to send a 6-digit random verification code to that number. The verification code is stored in the platform's cache with a validity period set (default 5 minutes). After the user enters the verification code, the platform compares the cached verification code with the user's input to see if they match and have not expired. If the comparison is successful, the mobile phone number is used as the user's globally unique identifier.

[0047] After successfully obtaining the identity identifier, the platform uses this identifier as the query condition to retrieve the historical binding relationship table `user_binding_history` in the database to check whether the user already has a valid binding relationship with other stores within the platform. The query logic is: `SELECT store_id FROM user_binding_history WHERE user_id = ? AND status = 'Valid'`. If the query result is empty (first use), the role assignment process proceeds directly; if the query result is not empty (already bound to another store), the platform pushes the "Switch Store" or "Add Association" option to the client for the user to choose from—when the user chooses "Switch Store", the platform sets the status of the original binding record to "Unbound" and creates a new binding; when the user chooses "Add Association", the original binding record is retained and a supplementary binding is created (the store initially bound is marked as the primary store, and subsequent bindings are marked as secondary stores).

[0048] After completing identity authentication and historical binding, the platform executes a role attribution deduction process. This deduction process is as follows: The platform uses the user's identity identifier and the current store identifier as a composite key to query a pre-defined identity-role mapping table. This mapping table is a persistent data storage structure pre-established on the platform server, using (user_id, store_id) as a combined unique index to store the role identifiers corresponding to the user's identity identifier and store identifier combination that has completed role binding. If a valid record corresponding to the composite key exists in the mapping table, the role identifier in that record is directly extracted as the deduction result, without requiring the user to reselect a role. The deduction process terminates early and proceeds to step four. If no corresponding record exists in the mapping table, the subsequent role strategy pool matching process in step three continues, obtaining a set of candidate role identifiers for the user to choose from. After the user selects a target role identifier, the platform creates an associated record in the mapping table with (user_id, store_id) as the composite primary key and the target role identifier as the mapping value, completing the instantiation of the user's role at the current store level. The mapping table is initially empty. All records are written when a user first completes the role selection. When the same user visits the same store again, the mapping table can be directly accessed to quickly complete the deduction.

[0049] The platform reads the store type field of the target store from the store touchpoint binding dataset generated in step two. This field can contain, but is not limited to, preset type identifiers such as restaurant and auto repair shop. The platform uses this store type value as the search index to query the pre-built store role strategy pool data structure. The store role strategy pool is a role configuration mapping table organized by store type, with the following structure: Store Type → Candidate Role Identifier List → Content Templates, Display Strategies, Push Rules, and Incentive Rules for Each Role.

[0050] like Figure 3 The diagram illustrates the ternary relationship. Specifically, the platform pre-configures a set of candidate role identifiers for each store type, for example: The set of candidate role identifiers for the restaurant store type is {chef, store manager, purchasing agent, apprentice}. The set of candidate role identifiers for the store type auto repair shop is {mechanic, store manager, purchasing agent, apprentice}. The platform extracts a set of candidate role identifiers from the role strategy pool based on the current store type and pushes this set to the client interface in list format. The client renders each candidate role identifier as a clickable option button, and the user clicks to select the corresponding role based on their actual function in the store.

[0051] After the user completes their selection, the client reports the target role identifier to the platform. Upon receiving the target role identifier, the platform server performs a triplet association storage: creating a record in the `user_binding_history` table, containing the user's identity identifier (`user_id`), store identifier (`store_id`), role identifier (`role_id`), binding creation time (`bind_time`), primary / secondary flag (`is_primary`), and binding status (`status`). The logic for the `is_primary` field is as follows: if the user has no historical binding records, it is marked as 1 (primary store); if a historical binding record exists and the user selected "Add Association," it is marked as 0 (secondary store).

[0052] This triple record constitutes the user-store role association object. All subsequent content push and behavior analysis will use the (user_id, store_id, role_id) combination in this association object as the query condition.

[0053] Step 4: Perform multi-level assembly of scenario-based push configuration for user-store role association objects, write scenario configuration parameters, and generate push configuration parameter set; In this embodiment, after the platform server completes the construction of the user-store role association object in step three, it uses the values ​​of the three fields role_id, store_id, and user_id in this object as input parameters to trigger a multi-level assembly process for contextualized push configuration. This assembly process executes four levels sequentially, with each level filtering or adjusting the output of the previous level.

[0054] The first level – Role Assignment: The platform retrieves content resources from a pre-defined resource library using `role_id` as the query condition. All content records stored in this library are pre-tagged with applicable role identifier fields (e.g., "Applicable Role = Chef" or "Applicable Role = ALL"). The query returns a list of all content resources whose applicable role identifiers match the current `role_id`, serving as a candidate content set. The core function of this level is to eliminate irrelevant content categories based on the user's role.

[0055] The second level—store filtering: The platform uses `store_id` as the query condition to retrieve the store attribute information (store type, product category, and region) stored in step two. Store affiliation filtering is then performed on the candidate content set output from the first level—it iterates through the candidate content set, checking whether the "applicable store type" field of each piece of content matches the current store type, and whether the "applicable product category" field matches the current store's product category. Content that does not meet either matching condition is removed from the set. The core function of this level is to remove content irrelevant to the actual operation of the current store.

[0056] The third level – timeliness filtering: The platform obtains the current system time and performs timeliness determination on the content set filtered by the second level. Each record in the content resource library is configured with a validity start time `valid_from` and a validity end time `valid_to`. The platform determines whether the current system time is within the time window [`valid_from`, `valid_to`] – if `valid_from` ≤ `now` ≤ `valid_to`, the content is retained; otherwise, it is discarded. The core function of this level is to ensure the validity of pushed content in the time dimension (such as seasonal recipes, holiday limited-time events, etc., which are only valid within the corresponding time period).

[0057] The fourth level – Behavioral Reordering: The platform retrieves a user's historical interaction records using `user_id` as the query condition. These records include content IDs the user previously clicked, video completion rates, and activity participation records. The platform calculates personalized weight scores for each piece of valid content filtered in the third level – frequently viewed content types are weighted, incomplete training content is weighted, and new content types never viewed before receive an exploration weight. After weight calculation, the platform sorts the content sets from highest to lowest weight score, placing content most likely to interest the user at the top of the set.

[0058] After completing the four levels, the platform will merge the content resources that have undergone four layers of processing—role matching, store filtering, timeliness screening, and behavior reordering—to generate scene configuration parameters. The data structure of the scene configuration parameters includes the following fields: role_id: Current role identifier; store_id: The identifier for the current store; access_time: Current access time; sorted_content_list: The final sorted list of content resources after four levels of processing (arranged in descending order of priority); role_config: The default configuration parameters for this role (read from the role policy pool); store_config: The unique configuration parameters for this store (read from the store profile); The platform writes the scenario configuration parameters into the extended storage field of the user-store role association object constructed in step three, completing data persistence. After writing, the platform extracts all configuration data from the user-store role association object and assembles it into a push configuration parameter set—this parameter set contains fields such as user identifier, store identifier, role identifier, scenario configuration parameters, and generation timestamp in a standardized data structure for subsequent content distribution processes to use.

[0059] Step 5: Perform message encapsulation on the push configuration parameter set to generate a content distribution message carrying role-differentiated tags, triggering the client to execute role-based content rendering according to the display strategy corresponding to the role-differentiated tags.

[0060] In this embodiment, the platform server obtains the push configuration parameter set generated in step four and calls the message encapsulation module to perform standardized encapsulation of the content distribution message.

[0061] The encapsulation process is as follows: The platform extracts the `role_id` field value from the push configuration parameter set and sets it as the role differentiation tag (`role_tag`) in the message header. It then extracts the `scene_config.sorted_content_list` field from the push configuration parameter set and reads the final sorted content data (including content title, content summary, content thumbnail address, content body address, and content type identifier) ​​item by item from the content resource library. Following a predefined message format, the role differentiation tag, content resource list, display configuration parameters, and other fields are assembled into a structured content distribution message. This message format must contain at least the following fields: role_tag: Role differentiation tag (taken from the role_id value configured by the user); content_items: A list of content resources (an array structure, each item containing subfields such as content ID, title, URL, type, and thumbnail); display_config: Displays configuration parameters (including page layout template identifiers, rendering rules for each section, etc.); generated_at: Message generation timestamp; The platform sends the encapsulated message to the user client via HTTP long connection or WebSocket protocol.

[0062] After receiving the content distribution message, the client executes the following processing flow: Step 1 – Parsing the message: The client performs deserialization parsing on the received JSON format message, extracts the role_tag field and content_items list, and verifies the timestamp field in the message (the deviation from the local time does not exceed a preset threshold).

[0063] The second step – matching the display strategy: The client uses the `role_tag` field value as an index to search for the display strategy corresponding to the current role in the locally pre-configured display strategy configuration file. The display strategy configuration file is JSON format data stored locally on the client, and each role identifier corresponds to a complete set of display strategy definitions – including parameters such as the page layout template identifier `layout_template`, the rendering order of each display area, the content filling rules for each section, and the interface theme color scheme.

[0064] Step 3 – Building the Page Framework: After the client completes the display strategy parsing, it builds the role-based page framework based on the `layout_template` configuration item in the display strategy. The `layout_template` describes the layout structure, functional areas, and arrangement of the display areas for the current role's corresponding page. The client generates the corresponding page container tree based on this layout structure and assigns a unique area identifier to each page container.

[0065] In this embodiment, the page framework includes at least five independent functional display areas: a product introduction area, an activity information area, a training and learning area, a check-in and interaction area, and a scenario quick reference area. Specifically, the product introduction area displays brand product images and text, brand culture information, and new product recommendations; the activity information area displays promotional activities, marketing tasks, and activity rules for the current store; the training and learning area displays training courses, video materials, and learning progress information relevant to the current role; the check-in and interaction area displays the check-in entry point, check-in status, and check-in statistics; and the scenario quick reference area displays product selling points, sales scripts, operating procedures, and immediate reference information relevant to the current work scenario. The client establishes independent content containers based on the area identifiers corresponding to each functional display area and configures corresponding data loading interfaces and rendering parameters for each content container, enabling each functional display area to independently complete content loading, partial refresh, and dynamic updates without rebuilding the overall page framework.

[0066] In this embodiment, the functional display areas are not displayed fixedly, but are dynamically loaded according to the region enable flag (region_enable) in the display strategy. When the corresponding region enable flag is enabled, the client creates the corresponding functional display area; when the corresponding region enable flag is disabled, the client skips the creation of the corresponding area and recalculates the layout positions of the remaining functional display areas to generate a page structure that is suitable for the current role.

[0067] Step 4 – Content Loading by Section: The client iterates through the `content_items` list of content resources and matches the loading rules of the corresponding display area according to the `content_type` field (text / image, video, card, etc.) of each content item. Text / image items are loaded into the product introduction or event information area, videos into the training and learning area, and cards into the scene quick reference area. Each display area calls its corresponding rendering engine to populate the content data into its respective container. The scene quick reference area has a timeout threshold for content loading (default 2 seconds). If the content is not loaded within 2 seconds, the client first renders a skeleton placeholder image, replacing it with the actual data upon arrival, ensuring that it does not interfere with the user's normal workflow.

[0068] Step 5 – Combined Presentation: After each display area is rendered, the client combines the rendering results of the five display areas in the order defined in the display strategy and presents them in the user interface. Users can then see differentiated content displays corresponding to their own role on the client.

[0069] Example 1: Closed-loop processing of interactive behavior acquisition and incentives In this embodiment, the user is a restaurant chef who has completed store binding and role configuration. The role identifier is CHEF, and the store type is RESTAURANT. This user repeatedly visits the same physical touchpoint over several consecutive days, triggering the following sequence of interactive behaviors: Sign-in behavior and consecutive sign-in bonus: Users check in at the check-in interaction area upon their first visit each day. The client captures this action, generates a CHECKIN event, and reports it to the platform. Upon receiving the event, the platform queries the user's historical check-in records and calculates the number of consecutive check-in days. The platform's configured check-in incentive rules are: a fixed base score for each check-in (e.g., 10 points), an additional 50% bonus for 3 consecutive check-ins, and doubled points for 7 consecutive check-ins. When the platform determines that the user's current consecutive check-in period is day 3, it calculates the incentive value as the base score plus 50%, and writes the result to the user's account. Simultaneously, the platform records this check-in event and updates the consecutive check-in count; the client interface refreshes to display the updated points balance and consecutive check-in status.

[0070] Training video learning and motivation: Users watch training videos matched to their roles in the training learning area. When the video playback progress reaches a preset completion threshold (e.g., 95%), the client reports a VIDEO_COMPLETE event, carrying the video identifier and viewing duration parameters. Upon receiving the event, the platform matches the corresponding incentive rule—which defines the training completion incentive as a random amount of money (with a preset value range, such as 0.5 to 3 yuan). After generating the random value, the platform writes it to the user's money account and pushes an incentive arrival message to the client via service notification.

[0071] Scene quick lookup and incentives: When a user clicks to view a reference information card (such as a recipe quick reference card) in the scene quick reference area, the client reports a SCENARIO_VIEW event. The platform matches this behavior with the incentive rule—a fixed score (e.g., 5 points) is awarded for the first time a user views scene quick reference content each day. If the platform determines that the user has not yet received this type of incentive for the day, the points are added to the user's account.

[0072] Unlockable red envelopes and repeat scan loop: After a user completes the check-in, the platform attaches information about a pending unlocked red envelope to the check-in response. This red envelope has preset unlocking conditions (such as scanning again within the next 48 hours) and an expiration time (if not claimed within 48 hours after the unlocking conditions are met, it expires). The platform records the status of this red envelope as "Pending Unlock". When the user triggers access again (RESCAN event) within the preset time window, the platform determines that the unlocking conditions have been met and updates the red envelope status to "Unlocked". After the user claims the red envelope, the platform transfers the amount to the user's available incentive account balance. If the user does not claim the red envelope within 48 hours after the unlocking conditions are met, the platform updates the red envelope status to "Expired". Subsequent rescanning by the user is also recorded as a rescanning cycle indicator in the user behavior profile, which participates in the weight calculation of the fourth-level behavior reordering in step four.

[0073] Example 2: Pre-emptive risk verification: Before generating incentive data, the platform calls the risk control verification module to perform pre-risk verification to prevent malicious traffic boosting, script attacks, and group control fraud.

[0074] The execution logic of the three checks is explained below using three specific scenarios: Electronic fence verification scenario: User A is a chef registered at store S1 (geographic coordinates longitude 121.47, latitude 31.23, electronic fence radius 500 meters). He accesses the physical touchpoint normally in the kitchen of store S1. The client reports GPS coordinates (longitude 121.47, latitude 31.23), which is approximately 10 meters away from the store coordinates. This distance is less than the electronic fence radius of 500 meters. The verification passes, and the user is allowed to proceed to the subsequent incentive distribution process.

[0075] User B claimed to be a chef at store S1, but their actual location was elsewhere (longitude 116.40, latitude 39.90, approximately 1100 kilometers from store S1). The distance between the GPS coordinates reported by the client and the coordinates of store S1, calculated using the Haversine formula, was approximately 1100 kilometers, significantly greater than the 500-meter radius of the electronic fence. Therefore, the verification failed. The platform intercepted the generation of this incentive data and marked the access record as an abnormal access event, storing it in the risk control log with the anomaly type labeled "beyond the electronic fence."

[0076] Device fingerprint verification scenarios: The platform uses the device fingerprint as the key to query the Redis cache for the number of behavioral events reported by the device in the most recent hour. Assuming device D1 is a mobile terminal owned by a normal user, and it reported 4 behavioral events in the most recent hour, which is less than the preset threshold of 50 events per hour, the verification passes.

[0077] Suppose that device D2 reports 127 behavioral events in the past hour, significantly exceeding the threshold of 50. The platform determines that the verification fails, blocks the generation of incentive data corresponding to the current access triggered by the device, and adds the device fingerprint to the key monitoring list.

[0078] Access frequency threshold verification scenario: The platform queries the access_log table in the database to count the number of access records for this user or device in the most recent hour. User U1 is a normal user, and the number of accesses in the most recent hour is 2, which is below the threshold of 20 times per hour, so the verification passes.

[0079] User U2 accessed the platform 35 times in the past hour, exceeding the threshold of 20 accesses. The platform determined that the verification failed, blocked the generation of incentive data, and marked the user as having a high-frequency access anomaly. Subsequent accesses by the user still completed the content display of steps one through five normally, but incentive distribution was suspended until the risk control module reassessed the user's behavior pattern and it returned to normal.

[0080] Comprehensive judgment logic: Each of the three checks outputs a pass or fail result. Only when all three checks are "pass" will the risk control check module generate a "risk assessment passed" result, allowing the process to proceed to the incentive value calculation stage. If any check result is "fail," a "risk assessment failed" result will be generated, the generation of incentive data will be blocked, and the anomaly type, occurrence time, associated user ID, and store ID of this access will be written to the risk control log table for subsequent review and statistical analysis by operations personnel.

[0081] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for binding store / person roles and pushing content based on NFC and QR codes, characterized in that, Includes the following steps: Extract the touch point identifier and touch point type fields from the client's NFC and QR code dual-mode access request messages to generate a unified touch point data object; Store files are retrieved using touchpoint identifiers as indexes, store identifiers and store attribute information are extracted, store touchpoint binding modeling is performed on the touchpoint identifiers and store information, store touchpoint binding objects are generated, and the data is aggregated to form a store touchpoint binding dataset. Obtain the user identity identifier of the accessing user, perform store role policy pool matching on the store touchpoint binding dataset, and perform role attribution inference on the user identity identifier to construct user-store role association objects; Perform multi-level assembly of contextualized push configuration for user-store role association objects, and generate content push configuration parameters; The content push configuration parameters are encapsulated to generate a content distribution message carrying a role-differentiated tag, which triggers the client to perform role-based content rendering according to the display strategy corresponding to the role-differentiated tag.

2. The method according to claim 1, characterized in that, The dual-mode access request for NFC and QR code specifically includes NFC access and QR code access: Receive access requests initiated by mobile terminals, parse the request type to determine the access method; When the access method is NFC, the contact identifier corresponding to the built-in chip of the physical contact is read. When the access method is QR code, the contact identifier carried by the QR code is parsed. The contact identifiers obtained by different access methods are uniformly converted into a format and combined with the contact type field to generate a unified contact data object.

3. The method according to claim 1, characterized in that, The process of modeling the store touchpoint binding includes: Read the touchpoint identifier from the unified touchpoint data object, retrieve the corresponding store profile information based on the touchpoint identifier; extract the store identifier, store location information, store type and store attribute information, establish an association mapping with the touchpoint identifier according to the preset field mapping rules, and generate the corresponding store touchpoint binding object, wherein the store touchpoint binding object is constructed through on-site deployment binding method and backend pre-binding activation method.

4. The method according to claim 3, characterized in that, The on-site deployment binding methods include: The system reads the touchpoint identifier corresponding to the physical touchpoint through the business terminal, enters the target store profile information and obtains the store location information; it then associates and binds the touchpoint identifier with the store identifier, submits the touchpoint identifier, store identifier and store location information to the platform server, generates the store touchpoint binding relationship, and updates the physical touchpoint binding status.

5. The method according to claim 3, characterized in that, The background pre-binding activation method includes: A pre-binding relationship between touchpoint identifiers and store identifiers is established in advance, and the physical touchpoints are configured to be in an activated state. The activation request submitted by the store terminal is obtained, and the consistency of the store identity information and store location information is verified. After the verification is passed, the physical touchpoint status is updated, and the corresponding store touchpoint binding relationship is generated.

6. The method according to claim 1, characterized in that, The process of matching the store role strategy pool includes: Read the store type information from the store touchpoint binding dataset, query the store role strategy pool using the store type as the retrieval index, and obtain a set of candidate role identifiers that match the current store type; push the set of candidate role identifiers to the accessing user, and determine the role identifier based on the target role identifier selected by the accessing user from the set of candidate role identifiers.

7. The method according to claim 1, characterized in that, The process of deducing user identity attributes includes: Using the combination key consisting of user identity and store identity as the query condition, perform an attribution matching query in the preset identity-role mapping table to deduce the corresponding role identity; construct a user-store role association object based on the deduced role identity.

8. The method according to claim 1, characterized in that, The execution process of the multi-level assembly includes: Using the role identifier in the user-store role association object as the first assembly level, a set of candidate content resources matching the current role is retrieved from the preset content resource library; using the store identifier as the second assembly level, store affiliation filtering is performed on the candidate content resource set; using the current access time as the third assembly level, timeliness filtering is performed on the filtered content resources, retaining content resources within their validity period; using the user's historical interaction records as the fourth assembly level, priority reordering is performed on the filtered content resources, adjusting the content resources preferred by the user to the front; the content resources processed through the four assembly levels are then fused to generate scene configuration parameters.

9. The method according to claim 1, characterized in that, The process of rendering the characterized content includes: The client receives and parses the role differentiation tags embedded in the content distribution message, and matches the content display strategy corresponding to the current role locally based on the role differentiation tags; according to the matched display strategy, the content data in the push configuration parameter set is rendered to the corresponding independent functional display area; each functional display area loads display content that matches its own area type according to the push configuration parameter set, and completes the combined presentation in the client interface.

10. The method according to claim 1, characterized in that, The rendering of the characterized content also includes a closed-loop processing procedure for user interaction behavior: The client pre-establishes a standardized set of interactive behavior events, captures various interactive operations generated by users in the function display area in real time, and generates structured behavior event data based on the captured interactive operations. The structured behavior event data is reported to the platform server, which matches the event type and event parameters in the behavior event data with preset incentive rules and generates corresponding incentive data. The incentive data is written to the user's account and a complete interactive behavior log is stored synchronously, forming a complete closed-loop link from user operation to incentive feedback.

11. The method according to claim 10, characterized in that, Before generating the corresponding incentive data, a preliminary risk verification process is also included: The platform server extracts the store location information, user terminal device characteristics information, and access behavior information for this visit; Perform electronic fence compliance verification on store location information to determine whether the access is within the store's valid service area; Perform device anomaly checks on device characteristic information to determine whether there is high-frequency access behavior of a single device; Perform access frequency threshold verification on access behavior information within a time period to determine whether the number of accesses within a unit time period exceeds the normal range; The access risk assessment result is generated by combining the results of the three verifications. When any one of the verifications fails, the incentive data is intercepted and the abnormal access event is recorded.

12. A system for binding store / person roles and pushing content based on NFC and QR codes, used to perform the method as described in any one of claims 1-11, characterized in that, include: The touch point parsing module is used to extract the touch point identifier and touch point type fields from the client's NFC and QR code dual-mode access request messages and generate a unified touch point data object. The store binding module uses touchpoint identifiers as indexes to locate target stores, establishes store touchpoint binding relationships corresponding to unified touchpoint data objects, and generates store touchpoint binding datasets. The role matching module is used to obtain the user identity identifier of the accessing user, perform store role policy pool matching on the store touchpoint binding dataset, and perform role attribution inference on the user identity identifier to build user-store role association objects; The content assembly module performs multi-level assembly of scenario-based push configurations for user-store role association objects, and generates a set of push configuration parameters; The push execution module encapsulates the push configuration parameter set into messages, generates a content distribution message carrying a role-differentiated tag, and triggers the client to execute role-based content rendering according to the display strategy corresponding to the role-differentiated tag.

Images