Business processing method, device, equipment, medium and product

Abstract

The embodiment of the invention provides a business processing method and device, equipment, a medium and a product. According to the scheme, the method comprises the following steps: after a first terminal displays a target page, switching a near field communication function of the first terminal to a silent state; acquiring sensor data acquired by a sensor of the first terminal; judging whether the first terminal has a collision event or not based on the sensor data; judging whether a second terminal colliding with the first terminal exists or not; and if the collision event occurs in the first terminal and a second terminal colliding with the first terminal exists, the first terminal displays a service page.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method for business processing. This specification also relates to an apparatus for business processing, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the development of computer technology, more and more business operations can be handled through mobile terminals, such as online or offline payments, receiving electronic coupons, and sending electronic business cards via smartphones. Furthermore, as mobile terminal functions become increasingly sophisticated, user interaction based on proximity is gradually becoming an important means of enhancing application experience. Currently, smartphones generally support Bluetooth, Near Field Communication (NFC), positioning, and various sensors (such as accelerometers). These capabilities are widely used in scenarios such as payments, social sharing, and interactive games to enable device discovery, connection, and information exchange. In some face-to-face interactive activities, users often complete operations by scanning codes, clicking to confirm, or manually pairing, with the overall process relying on explicit user input and a relatively long interaction path. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide methods, apparatus, devices, computer-readable media, and products for business processing to improve the convenience of user operations and the stability of interaction in face-to-face interactive activities.

[0004] According to a first aspect of one or more embodiments of this specification, a method for business processing is provided, comprising: After the target page is displayed on the first terminal, the near-field communication function of the first terminal is switched to a silent state; the first terminal in the silent state does not send or respond to near-field communication signals; Obtain sensor data collected by the sensors of the first terminal; Based on the sensor data, determine whether a collision event has occurred at the first terminal; Determine whether there is a second terminal that collides with the first terminal; If a collision event occurs on the first terminal and there is a second terminal that also collides with the first terminal, then the first terminal displays the service page.

[0005] According to a second aspect of one or more embodiments of this specification, an apparatus for business processing is provided, comprising: The state switching module is used to switch the near-field communication function of the first terminal to a silent state after the first terminal displays the target page; the first terminal in the silent state does not send or respond to near-field communication signals. The data acquisition module is used to acquire sensor data collected by the sensors of the first terminal; The collision detection module is used to determine whether a collision event has occurred at the first terminal based on the sensor data. The terminal determination module is used to determine whether there is a second terminal that collides with the first terminal; The page display module is used to display a service page on the first terminal if a collision event occurs on the first terminal and a second terminal collides with the first terminal.

[0006] According to a third aspect of one or more embodiments of this specification, a computing device is provided, including: a memory and a processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the above method.

[0007] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions which, when executed by a processor, implement the steps of the method described above.

[0008] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0009] One embodiment of this specification can achieve at least the following beneficial effects: by switching the near-field communication function of the first terminal to a silent state after displaying the target page, the NFC module is effectively prevented from generating unexpected interactions in the background due to tags, card readers or other devices in the environment, thus providing a clean and interference-free operating environment for sensor-based collision detection; on this basis, the collision event is autonomously judged in combination with local sensor data, and further verified whether there is a second terminal that is colliding synchronously, so that the service triggering condition does not depend on the action of one party, but is based on the reliable collaboration of spatiotemporal consistency between the two devices, which improves the real-time performance, reliability and user experience smoothness of face-to-face interaction, while reducing the false trigger rate and system resource consumption. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of a business processing method provided in one embodiment of this specification. Figure 2 A flowchart illustrating a business processing method provided in one embodiment of this specification; Figure 3 A swimlane diagram of a business processing method provided in one embodiment of this specification; Figure 4 This is a schematic diagram of the structure of a business processing apparatus provided in one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

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

[0013] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0014] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0015] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus 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, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0016] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0017] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0018] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0019] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0020] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0021] The following explains the terms and concepts used in one or more embodiments of this specification.

[0022] Bluetooth is a short-range wireless communication technology standard that operates in the 2.4 GHz ISM band and is mainly used for transmitting data between mobile devices (such as mobile phones, headphones, smartwatches, etc.).

[0023] Bluetooth advertising / broadcasting refers to the periodic transmission of broadcast data packets by Bluetooth devices (such as Bluetooth Low Energy (BLE) devices) in a non-connection-based manner. Other nearby devices can passively receive this data without prior pairing or connection. The broadcast content may include information such as device identification, service type, and timestamp.

[0024] NFC (Near Field Communication) is a short-range, high-frequency wireless communication technology operating in the 13.56 MHz frequency band, with an effective communication distance typically less than 10 centimeters. NFC supports three modes: peer-to-peer (P2P), reader / writer, and card emulation, and is commonly used in scenarios such as mobile payments, access control, and quick pairing.

[0025] NFC Silent Mode refers to a state in which NFC devices, under certain circumstances, do not actively send signals, information, or broadcast, remaining in a "quiet," "passive listening," or "respond-only" state. This avoids accidentally triggering other NFC devices to eject wallets.

[0026] Wi-Fi Direct is a technology that allows Wi-Fi devices to discover each other and establish peer-to-peer connections without the need for a router or access point (AP).

[0027] UWB (Ultra-Wideband) is a short-range wireless technology that uses an extremely wide spectrum (>500 MHz) to transmit data in nanosecond-level pulses, providing high-precision ranging and positioning capabilities.

[0028] Time synchronization refers to the process by which two or more devices adjust their local clocks to a consistent or mutually convertible state in order to accurately determine the order or concurrency of events in a distributed system.

[0029] Network Time Protocol (NTP) is an application-layer protocol in the TCP / IP protocol suite used for computer clock synchronization. This protocol supports server / client and broadcast modes, utilizing authoritative time sources such as atomic clocks and GPS to achieve local area network (LAN) time calibration. An NTP server provides an authoritative time source (usually from an atomic clock or GPS), and client devices can communicate with it via the internet to calibrate their local system time.

[0030] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0031] Figure 1 This is a schematic diagram illustrating an application scenario of a business processing method provided in one embodiment of this specification.

[0032] like Figure 1 As shown, assuming both terminal 10 and terminal 20 have entered an activity page, the user touches terminal 10 and terminal 20 together, for example, by bumping the top of terminal 10 against the side of terminal 20. Assuming both terminals have Bluetooth broadcasting and accelerometer monitoring enabled, terminal 10 and terminal 20 can detect the collision event. After confirming a collision, they can broadcast the time of the collision via Bluetooth. Terminal 10 can then confirm the collision with terminal 20 and display a service page, such as a page for receiving a red envelope, sending data, or exchanging electronic business cards. Terminal 20 can also display a corresponding service page. The service pages displayed by terminal 10 and terminal 20 can be the same or different. The specific service page can be determined based on the actual business processing logic; no specific limitations are made here.

[0033] When at least two terminals collide with each other, only the colliding terminal can display the corresponding service page. This avoids accidental triggering of services by a single terminal touching an object such as a table or backpack, improving the stability of service processing. Furthermore, by detecting collision events to trigger the display of the service page, the user does not need to touch specific locations on the two terminals. For example, the user does not need to determine the touch location based on the position of the terminal's NFC coil. In one embodiment of this specification, the user can collide any part of at least two terminals, further improving user convenience. The first and second terminals can be, but are not limited to, mobile or portable devices such as smartphones, tablets, laptops, PDAs, smartwatches or bracelets, personal computers, and smart home devices. The first and second terminals can be the same type of device or different types of devices. For example, both the first and second terminals can be smartphones; or the first terminal can be a smartphone and the second terminal a tablet; or the first terminal can be a smartphone and the second terminal a smartwatch or bracelet, etc. The specific types of the first and second terminals are not limited here.

[0034] This application provides a method for business processing, and also relates to a business processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0035] Figure 2 This is a flowchart illustrating a business processing method provided in one embodiment of this specification.

[0036] From a procedural perspective, the entity executing the process can include a program mounted on an application terminal. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities. Here, we will use the first terminal as the executing entity for illustration.

[0037] like Figure 2 As shown, the process may include the following steps: Step 202: After the target page is displayed on the first terminal, switch the near-field communication function of the first terminal to silent mode.

[0038] In this silent state, the first terminal neither sends nor responds to near-field communication (NFC) signals. The first terminal can refer to any mobile terminal device (such as a smartphone, tablet, etc.) participating in a service processing method according to one embodiment of this specification, used for face-to-face interaction with another terminal (i.e., the second terminal). The first terminal can be a terminal equipped with a terminal application, which may include a program to switch the NFC function of the first terminal to a silent state. The NFC function of the first terminal can be switched to a silent state through software control, which is imperceptible to the user. The user does not need to manually turn off the NFC function of the first terminal.

[0039] The target page can represent a specific user interface preset in the application, used to trigger interactive functions through collision, and can trigger the terminal to enter a silent state. For example, it can be a page displayed before displaying subsequent business pages, or it can be a business activity page, or it can be a page for a game or a page for entering a game, etc.

[0040] To prevent two terminals from accidentally entering NFC card emulation mode and popping up the NFC card application interface when they are close to each other, thus avoiding accidental card packet pop-ups, or to prevent NFC communication with other nearby devices, this can improve the accuracy of business processing, reduce interference to users, and ensure the stability of interaction between the first and second terminals.

[0041] In one embodiment of this specification, after the target page is displayed on the terminal, the terminal can be switched to a silent state. If the second terminal also displays the target page, the near-field communication function of the second terminal can also be switched to a silent state. In practical applications, the target page displayed on the first terminal and the target page displayed on the second terminal can be the same service-related page, and the specific page content can be the same or different.

[0042] In practical applications, the application on the first or second terminal can determine whether the terminal is displaying the target page based on the content of the currently displayed page or information such as the page identifier (e.g., page ID). If the terminal is currently displaying the target page, it can switch to NFC silent mode. For example, when a user opens an application and loads the target page, the application can call the NFC management interface provided by the operating system to disable the NFC card emulation mode via API, and / or disable the NFC controller's polling function, stopping the active detection of nearby NFC tags or devices. The NFC chip can still be powered, but only in a low-power listening state, not actively emitting radio frequency fields, or not responding to external read requests, or it can also start polling once at preset intervals. Step 204: Obtain sensor data collected by the sensor of the first terminal.

[0043] Step 206: Based on the sensor data, determine whether a collision event has occurred at the first terminal.

[0044] The first terminal can have built-in physical sensing units such as speed sensors, acceleration sensors, and angle sensors to sense the terminal's movement status. Sensor data can represent raw or pre-processed numerical sequences output by the sensors, such as acceleration data along the x, y, and z axes, or the first terminal's direction of movement. In practical applications, sensor data can be stored as a pair of timestamps and sensed values ​​to determine the first terminal's movement status over a period of time or at a specific moment. In practical applications, with authorization, the application can monitor the sensor data collected by the sensors to determine subsequent collision events. For example, after the first terminal displays the target page, the application can monitor the sensor data sensed by the first terminal's sensors. By continuously acquiring high-frequency sensor data, a sufficient data foundation is provided for accurately identifying the time point and characteristic features of collision events, improving the sensitivity and timeliness of motion detection.

[0045] Similarly, for the second terminal, the application in the second terminal can also obtain the sensor data collected by the sensors of the second terminal, and then determine whether a collision event has occurred on the second terminal.

[0046] In practical applications, it is possible to determine whether a collision event has occurred on the terminal by setting preset rules, or by making a judgment based on a pre-trained evaluation model, or by combining rule-based judgment with model-based judgment.

[0047] In one implementation, the sensor data may include acceleration data and / or motion direction data of the first terminal in at least one of the horizontal, vertical, and depth directions; determining whether a collision event has occurred at the first terminal may include: determining whether the sensor data satisfies preset characteristics; if the preset characteristics are satisfied, then determining that a collision event has occurred at the first terminal. The preset characteristics include at least one of the following: the acceleration value represented by the acceleration data is greater than or equal to a preset threshold; the acceleration data shows an initial increase followed by a decrease within a preset time window, and the peak width is less than or equal to a preset peak width; the magnitude of the change in motion direction of the first terminal in at least two of the horizontal, vertical, and depth directions is greater than or equal to a preset magnitude.

[0048] The horizontal, vertical, and depth directions can represent directions in a three-axis coordinate system with the first terminal as the reference frame. For example, the horizontal direction can represent the left-right direction of the first terminal, also known as the X-axis; the vertical direction can represent the up-down direction of the first terminal, also known as the Y-axis; and the depth direction can represent the screen orientation or front-back direction of the first terminal, also known as the Z-axis. Alternatively, the directions of the coordinate system can be set according to actual needs.

[0049] Acceleration data can represent data output by an accelerometer, used to reflect changes in the force acting on the first terminal. Motion direction data can represent data output by a direction sensor, used to reflect the motion direction of the first terminal, or changes in motion direction, or it can be the trend of changes in the acceleration direction, or velocity / displacement direction information obtained by integrating / filtering the acceleration, used to determine the overall motion attitude of the device. Both can be used individually or in combination.

[0050] One collision detection rule could be that the total acceleration value of one axis (e.g., the Z-axis), two axes (e.g., the X-axis and Z-axis), or three axes exceeds a certain threshold (e.g., 2g), which would be considered a collision. In practical applications, a collision generates an instantaneous impact force, causing a significant increase in acceleration along a certain axis. When the acceleration value represented by the acceleration data of one or more axes is greater than or equal to the preset threshold, a collision event can be determined to have occurred on the terminal. This allows for the rapid elimination of low-intensity disturbances (such as hand-held shaking or walking bumps). The preset threshold can be set according to the actual situation, for example, it could be 2g to 4g, or it could be other thresholds.

[0051] Another collision detection rule can be based on a time window. A pre-set action detection window can be used. For example, if acceleration rises rapidly and then falls rapidly within 500ms of continuous data collection, forming a clear peak with a short peak width, a collision event can be identified. In practical applications, when two or more terminals collide, it is a short-duration pulse event. The waveform can be spike-like and the duration is short, for example, less than or equal to 200ms. If the acceleration data of one or more axes shows a rise followed by a fall within the preset time window, and the peak width is less than or equal to the preset peak width, a collision event can be identified. The preset time window can be used to define the analysis interval; the peak width can represent the duration of acceleration exceeding a threshold. If it is too wide (e.g., >300ms), it may be a drop or pressure, not an instantaneous collision. This can distinguish between instantaneous collisions and continuous force (such as being pressed on a table), allowing for more accurate detection of collisions between terminals. The preset time window and preset peak width can be set according to the actual situation. For example, the preset time window can be 300ms to 800ms, and the preset peak width can be 50ms to 200ms, or other thresholds.

[0052] Another collision rule can be based on changes in direction. In practical applications, judging based solely on the degree of change in a single direction is prone to misjudgment (e.g., a phone dropped). In one embodiment of this specification, the judgment can be made by combining changes in the direction of at least two of the X, Y, and Z axes. For example, if all three dimensions (X, Y, and Z) undergo synchronous and drastic changes within a short period of time, that is, if the magnitude of the change in the motion direction of the first terminal in at least two of the horizontal, vertical, and depth directions is greater than or equal to a preset magnitude, it can be determined that a collision event has occurred. The magnitude of the change in motion direction can be understood as the change in the direction angle of the acceleration vector, or a coordinated abrupt change in the sign / magnitude of the acceleration along each axis. This can improve anti-interference capabilities and cope with collision recognition under complex handheld postures.

[0053] In practical applications, collision detection can be performed based on one or more of the three rules mentioned above. If collision detection is based on multiple rules, the various detection rules can be executed synchronously in parallel or asynchronously in sequence. As one implementation, if the sensor data of the first terminal satisfies any of the above detection rules (i.e., preset features), a collision event can be determined to have occurred at the first terminal. As another implementation, if multiple detection rules (features) are included, and the sensor data of the first terminal satisfies all of the included detection rules (preset features), a collision event can be determined to have occurred at the first terminal.

[0054] In one embodiment of this specification, by defining multi-dimensional preset features including acceleration threshold, velocity waveform morphology, and spatiotemporal multi-axis coordinated changes, a collision determination is triggered when any or multiple features are satisfied. This can improve the sensitivity of recognizing real-time collision actions and effectively suppress false judgments caused by single-point false detections (such as falling, shaking, or pressing), thereby enhancing the accuracy and environmental adaptability of collision detection.

[0055] As another implementation, determining whether a collision event has occurred at the first terminal may include: providing the sensor data to a collision event evaluation model; the collision event evaluation model is a pre-trained lightweight machine model; obtaining an evaluation result generated by the collision event evaluation model; the evaluation result is either an evaluation result indicating that a collision event has been sent or an evaluation result indicating that no collision event has occurred.

[0056] The collision event evaluation model can represent a machine learning model used to classify or regress sensor data. Its output can be a binary decision, such as a character indicating whether a collision occurred or not, or a character representing the probability of a collision. This model can be one that has already been trained on a server or in a development environment using labeled samples. It can be a lightweight model, characterized by small size, low inference computation, and low memory usage. In practical applications, this model can be downloaded from the server and cached locally on the terminal application upon initial startup or update, allowing subsequent inference to be performed offline without an internet connection.

[0057] In practical applications, the training platform can collect multiple sets of action data from actual collisions between terminals (such as data from different models, forces, angles, etc.); it can also collect negative samples (such as action data from terminals during drops, shaking, and tapping on a table). Then, time-domain / frequency-domain features are extracted or the raw acceleration sequences are directly input into the machine learning model to be trained, such as lightweight models (e.g., MobileNetV2, TinyMLP, 1D-CNN, etc.). The model is trained to obtain an evaluation model that can be used to assess collision events involving terminals. Alternatively, to facilitate terminal use, the trained model can be quantized and pruned, compressed to suit mobile deployment. The model can be loaded into memory when the terminal application starts or after the target page is displayed. The terminal application can also acquire real-time sensor data from the terminal (such as triaxial acceleration in the last 500ms), preprocess it (e.g., normalization, frame segmentation, etc.), and then input it into the model; the model then provides the evaluation results.

[0058] In one embodiment of this specification, by deploying a pre-trained machine learning model locally on the terminal and using it to intelligently evaluate sensor data, it is possible to efficiently and accurately distinguish between real collision events and complex environmental interference without relying on network connectivity, significantly improving the generalization ability and robustness of collision recognition, while ensuring user data privacy and real-time interaction.

[0059] As another implementation, rule-based judgment and model-based judgment can be combined to determine whether a collision event has occurred at the terminal. The determination of whether a collision event has occurred at the first terminal may include: based on the sensor data, determining whether the sensor data meets preset characteristics to obtain a judgment result; providing the sensor data to a collision event evaluation model to obtain an evaluation result generated by the collision event evaluation model; and performing a fusion decision based on the judgment result and the evaluation result to determine whether a collision event has occurred at the first terminal.

[0060] Among them, fusion decision can represent the result of comprehensive rule judgment and evaluation model output, and the final judgment is obtained through logical combination (such as "AND", "OR", "weighted voting", "confidence fusion" etc.).

[0061] For example, rules can be used to determine whether the terminal's sensor data meets preset characteristics. Sensor data can also be synchronously provided to an evaluation model. If one or both results from the rule-based or model-based judgments indicate that a collision event has occurred, it can be determined that a collision event has occurred. Alternatively, a rule-based judgment can be performed first; if the rule-based judgment determines that no collision event has occurred, the model can then be used for further judgment. Or, after obtaining the judgment and evaluation results, a weighted calculation can be used to determine the final collision probability, thereby comprehensively determining whether a collision event has occurred.

[0062] By fusing physics-based rule-based judgments with AI model-based evaluation results, the system retains the interpretability and low computational overhead advantages of rule-based methods while introducing the AI ​​model's ability to recognize complex patterns. This effectively improves the overall performance of collision event detection in diverse usage scenarios, significantly reduces false alarm and false negative rates, and maintains the real-time processing and privacy security of the terminal side.

[0063] In practical applications, the second terminal can also determine whether a collision event has occurred using the same method described for the first terminal. This will not be elaborated further here.

[0064] Step 208: Determine whether there is a second terminal that collides with the first terminal.

[0065] In practical applications, the first terminal can detect the presence of a second terminal nearby using a distance sensor. If a second terminal is present within a preset range, it indicates that a second terminal has collided with the first terminal. Alternatively, the first terminal can determine the presence of a second terminal nearby through short-range information broadcasting. For example, the first terminal can broadcast a detection message via Bluetooth. If it receives a response from another terminal, it can confirm the presence of a second terminal nearby, which also indicates that a second terminal has collided with the first terminal.

[0066] To more accurately determine the existence of a second terminal that collided with the first terminal, the time of the collision between the first and second terminals can also be used to determine whether a second terminal colliding with the first terminal exists. As one implementation, the method in one embodiment of this specification may further include: if a collision event occurs at the first terminal, determining a first timestamp of the collision event; and sending the first timestamp via short-range communication. The determination of whether a second terminal colliding with the first terminal exists may include: determining whether collision confirmation information sent by the second terminal via short-range communication is obtained within a first preset time period; the collision confirmation information is generated by the second terminal after the difference between the second timestamp of the collision event and the first timestamp of the first terminal is less than or equal to a preset difference; if collision confirmation information sent by the second terminal via short-range communication is obtained within the first preset time period, then it is determined that a second terminal colliding with the first terminal exists.

[0067] The first and second timestamps can represent the moments when the first and second terminals determine that a collision event has occurred (e.g., millisecond-level Unix timestamps or relative startup times). In practical applications, the terminal can identify characteristic waveforms from continuously acquired sensor data streams and mark key time points as collision moments. For example, the rising edge of the waveform indicates the instant of contact, where acceleration increases rapidly; the peak value indicates the moment of maximum impact force; and the falling edge can indicate rebound or energy dissipation, where acceleration decreases. The first and second timestamps can be determined based on the peak moment or the start time of the rising edge of the collision characteristic signal in the sensor data. As one implementation, the peak acceleration moment can be used as the collision moment. For example, the terminal can continuously acquire triaxial acceleration data (e.g., a 100Hz sampling rate, one sample every 10ms); when the total acceleration exceeds a threshold (e.g., 2g), an event window (e.g., 500ms) can be started; the sampling point time corresponding to the maximum acceleration value can be found within the window; and the timestamp of this sampling point can be recorded as the collision moment. As another implementation, the starting point of the rising edge can also be used as the collision moment. Specifically, the timestamp corresponding to the sampling moment when the acceleration reaches its maximum value in the sensor data can be determined as the collision moment. For example, the rate of change of acceleration (da / dt) can be monitored; when the rate of change exceeds a preset slope threshold (such as a sudden increase from 1 g / s to 50 g / s), it can be determined that a collision has begun; the timestamp of this abrupt change can be used as the collision moment.

[0068] Short-range communication can be achieved through at least one of the following near-field wireless communication technologies: Bluetooth, Wi-Fi Direct, and UWB. However, to further prevent accidental card ejection, NFC (Near Field Communication) may not be included in this definition of short-range communication.

[0069] Collision confirmation information can be a message actively generated and broadcast by the second terminal after receiving the first terminal's first timestamp and the difference between the second terminal's time and its own collision time is less than or equal to a preset difference. This information indicates that a collision event has occurred between the first terminal and the second terminal. The collision confirmation information may include an ACK flag, the device IDs of both parties, timestamp pairs, and other information.

[0070] The first preset time period can represent the timeout window (e.g., 500ms) during which the first terminal waits to receive confirmation information from the other party after sending its own timestamp. If no confirmation is received within the timeout period, it is considered that there is no valid second terminal, thus avoiding infinite waiting and confirming that there is no second terminal colliding with the first terminal, and the first terminal will not display the business page.

[0071] The preset difference can represent a time tolerance threshold (e.g., 50ms, 100ms) to tolerate errors such as local clock drift and communication delay. Its value can be less than the perceived duration of a touch action (e.g., less than 200ms) to ensure the synchronization of the collision.

[0072] In practical applications, the first terminal can record the first timestamp T1 of the collision after detecting a collision; then, it can broadcast a light burst information containing this timestamp and the terminal device identifier (such as device ID) via Bluetooth, and simultaneously start a timer (e.g., 500ms) to listen for surrounding broadcasts. If the second terminal receives the broadcast from the first terminal, the second terminal can buffer T1; if the second terminal itself also detected a collision recently (e.g., within ±200ms), it determines the second timestamp T2 of the collision; the second terminal can calculate the difference between the two timestamps, and if the difference is less than a preset difference, it can generate a collision confirmation message and broadcast it via Bluetooth. If the first terminal receives the collision confirmation message within a preset time (e.g., within 500ms after sending the broadcast), it can determine that a second terminal has collided with the first terminal, and the first terminal can display the service page. Similarly, the second terminal can also display the service page after determining that the difference between the two timestamps is less than the preset difference. Alternatively, the second terminal can choose not to display the service page, depending on actual business needs. In practical applications, if three or more terminals collide simultaneously, at least one of them can be a second terminal, which can receive the collision timestamps sent by the other terminals and perform difference judgment.

[0073] In one embodiment of this specification, a highly efficient and reliable verification of synchronous physical collision events across multiple terminals is achieved by generating a collision timestamp locally on the terminal, exchanging time information using short-range communication, and confirming the collision based on a preset time difference threshold. Furthermore, the entire process requires no network connection or server involvement, significantly improving the real-time performance, privacy, security, and anti-interference capabilities of the interaction, while effectively preventing invalid service triggering caused by unilateral false detections.

[0074] In practical applications, the collision time can also be determined by the first terminal. As another implementation, the method in one embodiment of this specification may further include: if a collision event occurs at the first terminal, determining a first timestamp of the collision event; and sending the first timestamp via short-range communication. The determination of whether a second terminal collides with the first terminal may include: determining whether a second timestamp sent by the second terminal via short-range communication is obtained within a second preset time period; the second timestamp is the timestamp of the collision event at the second terminal; if the second timestamp is obtained, determining whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference; if the difference between the first timestamp and the second timestamp is less than or equal to the preset difference, then determining that a second terminal collides with the first terminal.

[0075] Similar to the above logic type, if the second terminal acts as the timestamp sender, after determining the time of its own collision, it can also send information containing the second timestamp via short-range communication methods such as Bluetooth broadcast. If the first terminal obtains this second timestamp and a collision event occurs on the first terminal, it can calculate the difference between its own first timestamp and the second timestamp. If this difference is less than or equal to a preset difference, it can be determined that a collision has occurred between the first and second terminals, and the first terminal can display the service page. If the first terminal has not determined the first timestamp, meaning the first terminal has not experienced a collision event, and only the second terminal has, the first terminal does not meet the conditions for displaying the service page, and therefore, the first terminal does not display the service page.

[0076] To facilitate the second terminal's determination of whether a first terminal has collided with it, the first terminal can also send an acknowledgment notification to the second terminal after determining that a collision event has occurred between the second terminal and the first terminal. Optionally, the method in one embodiment of this specification may further include: if the difference between the first timestamp and the second timestamp is less than or equal to a preset difference, then sending collision confirmation information via short-range communication; the collision confirmation information is used to indicate that a collision has occurred between the first terminal and the second terminal.

[0077] Similar to the embodiments described above, the collision confirmation information can be generated by the first terminal after determining that the difference between the first timestamp and the second timestamp is less than or equal to a preset difference. It can be sent out via short-range communication methods such as Bluetooth, Wi-Fi Direct, and UWB. Details identical or similar to those in the embodiments described above will not be repeated here.

[0078] In practical applications, after determining that a collision event has occurred, both the first and second terminals send out the time of their respective collisions so that the other party can make its own judgment. As one implementation, the method in one embodiment of this specification may further include: if the first terminal experiences a collision event, determining a first timestamp of the collision event; obtaining a second timestamp sent by the second terminal via short-range communication; the second timestamp is the timestamp of the second terminal's collision event. The determination of whether a second terminal has collided with the first terminal may include: determining whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference; if the difference between the first timestamp and the second timestamp is less than or equal to the preset difference, then determining that a second terminal has collided with the first terminal.

[0079] Before or after the first terminal sends out its first timestamp, it can monitor nearby broadcast information. If it obtains the second timestamp within a preset time period (e.g., 1 minute) after displaying the target page, or within a preset time period (e.g., 200ms) after sending the first timestamp, it can perform a difference judgment. If it does not obtain the second timestamp information within the preset time period, it can perform a difference judgment and determine that there is no second terminal that collides with the first terminal's transmission.

[0080] In practical applications, the process executed by the second terminal can be similar to or the same as that of the first terminal. For example, if the second terminal obtains the first timestamp sent by the first terminal, the second terminal can also determine whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference. If the difference is less than or equal to the preset difference, it is determined that there is a first terminal that has collided with the second terminal, and the second terminal can also display the business page triggered by the collision event. For more details on the processing flow, please refer to the aforementioned description of the first terminal, which will not be repeated here.

[0081] In practical applications, the server can also determine whether a second terminal collides with the first terminal. As one implementation, determining whether a second terminal collides with the first terminal may include: If a collision event occurs at the first terminal, the first timestamp of the collision event is sent to the server. Based on the first timestamp, the server determines whether there is a second terminal that collides with the first terminal; the second terminal that collides with the first terminal is a terminal whose distance from the first terminal is less than or equal to a preset distance and whose difference between the provided second timestamp and the first timestamp is less than or equal to a preset difference. If a second terminal collides with the first terminal, then service data is sent to the first terminal; The first terminal displays a service page based on the service data.

[0082] If there is no second terminal that collides with the first terminal, the server may not send business data to the first terminal, and the first terminal may not display the business page.

[0083] The server can refer to the application server, which can receive collision event data reported by multiple terminals and execute judgment logic. After confirming the existence of a valid second terminal, that is, after a collision has occurred between the first terminal and the second terminal, the server can return the business content to the first terminal, thus avoiding invalid delivery.

[0084] For example, after detecting a collision, the first terminal can record the first timestamp T1 of the collision; it can also obtain its current location (such as GPS or Bluetooth Beacon ID) and send the first timestamp and location information to the server. Alternatively, the server can determine the terminal's location based on the device identifier, without requiring the terminal to report. The second terminal can detect a collision simultaneously, slightly later, or slightly before the first terminal, record the second timestamp T2 of the collision, and send the second timestamp and its location information to the server. In practical applications, multiple terminal collisions may occur simultaneously or within the same time period. The server can receive multiple reporting records. The server can determine the second terminal closest to the first terminal based on the location information sent by the first or second terminal. It can also determine if the difference between the timestamp provided by the second terminal and the timestamp provided by the first terminal is small. If all conditions are met, it can be determined that a collision has occurred between the first and second terminals, and the server can send service data to the first and / or second terminals. The first and / or second terminals can receive the service data and render and display the service page.

[0085] By uploading collision timestamps to a server, which then performs centralized collaborative judgment based on preset distance and time difference thresholds, effective identification of synchronous collision events across multiple terminals can be achieved even when terminal computing power is limited or network environments are complex. Furthermore, unified server-side verification facilitates the implementation of anti-cheating, frequency-limiting, and differentiated reward policies, thereby improving the manageability and security of terminal applications.

[0086] Step 210: If a collision event occurs on the first terminal and there is a second terminal that collides with the first terminal, then the first terminal displays the service page.

[0087] The second terminal can refer to another mobile terminal that collides with the first terminal. The second terminal can be one terminal or multiple terminals. For example, mobile phone A collides with mobile phone B, or mobile phone A, mobile phone B, and mobile phone C collide simultaneously.

[0088] One-way collisions cannot confirm whether it is a two-person interaction or a single person's misoperation (such as a phone hitting a table). In one embodiment of this specification, the first terminal will only display the business page after it is determined that a collision event has occurred on the first terminal and there is a second terminal that has collided with the first terminal. By displaying the business page only after both conditions are met, the accuracy of business triggering and consistency with user perception are ensured, invalid or incorrect business displays are avoided, the credibility and satisfaction of the interaction are improved, and user disturbance is reduced, thereby improving the accuracy of business processing.

[0089] A business page can refer to a business page that can be triggered by a collision event. It can be an interface that carries specific benefits or functions, such as a red envelope receiving page or a card display page, and belongs to the higher-level function description. As one implementation method, the business page includes at least one of the following: a virtual resource receiving or sending page, a file transfer page, an information sharing page, and an add friend page.

[0090] The virtual resource claiming or sending page can represent how users can acquire or grant digital rights through a collision action, such as receiving red envelopes, coupons, electronic cards, or game items. The file transfer page can represent a page for exchanging files between devices based on a collision, such as transferring photos, sending documents, or sharing videos. The information sharing page can represent a page for sharing personal or content information, such as sharing business cards, sending location, or syncing playlists. The add friend page can represent a page for establishing social relationships, such as adding friends face-to-face or joining groups by tapping. After successful collision verification, the first device can directly jump to the page to confirm adding XXX as a friend, without manually entering an ID or scanning a QR code.

[0091] In practical applications, the business page can be displayed between the first terminal and the second terminal via short-range communication, or it can be a business page fed back from the application server to the terminal for display. As one implementation, if a second terminal collides with the first terminal, the first terminal displays a service page, including: If a second terminal collides with the first terminal, the first terminal sends a result information indicating that a collision has occurred to the server; the server then sends service information back to the first terminal based on the result information. The first terminal displays a service page based on the service information.

[0092] In practical applications, after the first terminal completes local collision detection and confirms the existence of the second terminal, it reports the successful collision event (which may include user ID, activity ID, timestamp, etc.) to the business server via cellular network or Wi-Fi. After verifying the legitimacy of the request, the server generates corresponding business data (such as red envelope amount, coupon ID, permission token, etc.) and returns it to the first terminal. The first terminal parses the data, renders and displays the business page (such as "Congratulations on receiving a 5 yuan coupon"). Specific application scenarios may include, but are not limited to: virtual resource distribution (such as red envelopes, points, coupons, etc.), businesses requiring centralized verification or risk control (such as limited-edition gifts, identity authentication, etc.), and activities involving multiple participants (such as "three-person bumping team").

[0093] As another implementation, if a second terminal collides with the first terminal, the first terminal displays a service page, including: If a second terminal collides with the first terminal, the first terminal sends service data to the second terminal via short-range communication, or receives service data sent by the second terminal via short-range communication. Based on the aforementioned business data, a business page is displayed. (This includes local data that can be transmitted via Bluetooth, such as business cards, electronic keys, room cards, and documents.) In practical applications, after the first and second terminals complete collision verification, they can negotiate to establish a point-to-point short-range communication link (such as BLE high-speed transmission, Wi-Fi Direct, etc.). Business data is exchanged directly between the two ends. For example, the target page can be a page of a terminal application. After both the first and second terminals open the same terminal application, the first terminal displays its electronic business card in that application. After a tap, the first terminal can send its electronic business card to the second terminal, which can receive the electronic business card through its launched terminal application. Alternatively, the two parties can exchange encrypted session keys. The first terminal displays the corresponding page (such as "Business card sent" or "Friend request received") based on the received data (or the status of its own sent data). Specific application scenarios may include, but are not limited to: file / media transfer (such as photos, documents, videos), information sharing (such as contact information, location, playlists), P2P social networking (such as adding friends, creating groups), etc.

[0094] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0095] Figure 2 The method described above effectively prevents the NFC module from accidentally interacting with tags, card readers, or other devices in the background by switching its near-field communication function to a silent state after the target page is displayed on the first terminal. This provides a clean and interference-free operating environment for sensor-based collision detection. On this basis, the collision event is autonomously judged by combining local sensor data, and the existence of a second terminal that is colliding synchronously is further verified. This makes the business triggering condition not only dependent on unilateral actions, but also based on a reliable collaboration between the two devices with spatiotemporal consistency. This improves the real-time performance, reliability, and user experience smoothness of face-to-face interaction, while reducing the false trigger rate and system resource consumption.

[0096] To further improve the accuracy of collision event detection, the first terminal and the second terminal can be synchronized in time, and the collision event can be judged based on the same time reference. As one implementation, before determining the first timestamp of the collision event, the process may further include: synchronizing the first terminal and the second terminal in time, so that the first terminal and the second terminal have the same reference time.

[0097] Determining the first timestamp of the collision event may include: determining the first timestamp of the collision event based on the reference time.

[0098] Time synchronization can mean aligning the local clocks of the first and second terminals to the same time reference system as much as possible, reducing time discrepancies between them. A shared reference time means sharing an interchangeable time reference within an acceptable error range, making the timestamps recorded by each terminal comparable. This reference time can be a relative time, such as local timing starting from a Bluetooth broadcast, or an absolute time, such as UTC (Coordinated Universal Time) obtained via NTP.

[0099] In practical applications, time synchronization can be achieved via Bluetooth broadcast or by using an NTP server. The process of time synchronization via Bluetooth broadcast generally includes: assuming a first terminal sends a time synchronization request via Bluetooth broadcast (the first terminal is the master device), and a second terminal receives the request (the second terminal is the slave device). The master device sends a broadcast with a timestamp T01 generated based on its local clock. This timestamp can be in the millisecond or even nanosecond range. After receiving the synchronization request, the slave device can record the timestamp T02 of receiving the request based on its own local clock. It can also send a response message to the master device carrying timestamps T02 and T03, where timestamp T03 is the local time at which the slave device sent the response message. After receiving the response information, the master device can record a timestamp T04 based on its local clock, representing the moment the response was received. It can then calculate the total round-trip delay using Delay_total = (T04 - T01) - (T03 - T02), and obtain the one-way delay using Delay_single = Delay_total / 2. The master device can also calculate the clock offset between the slave and master devices using the formula Offset = (T02 - T01) - Delay_single, and feed this one-way delay and clock offset value back to the slave device. The slave device adjusts its own real-time clock or records the clock offset value based on the received one-way delay and clock offset value to achieve time synchronization with the master device. In practical applications, the first terminal can also act as a time synchronization slave device, and the second terminal as a time synchronization master device. The logic is similar to the above and will not be elaborated further here.

[0100] The process of time synchronization via an NTP server generally includes: both the first terminal and the second terminal connect to the same NTP server; after the first terminal and the second terminal display the target page, they can obtain high-precision UTC time from the NTP server respectively; subsequent collision timestamps can use this UTC time (or convert it to millisecond-level timestamps).

[0101] In one embodiment of this specification, a unified time reference is established by synchronizing the time of the first terminal and the second terminal before collision detection (e.g., based on Bluetooth broadcast or NTP server), making the collision timestamps generated by both parties highly comparable. Based on this, time difference judgment is performed, which significantly reduces false or missed judgments caused by the drift of the terminal's local clock. This not only improves the accuracy of synchronous collision recognition, but also allows for the use of stricter time thresholds, enhancing the security and anti-interference capabilities of the interaction.

[0102] As another implementation, the first terminal and the second terminal can generate timestamps of the collision events based on their local clocks, and then calculate the difference between the collision events by combining the deviation of the local clocks, which can also improve the accuracy of detection. Optionally, the first timestamp is a timestamp determined by the first terminal based on its local clock, and the second timestamp is a timestamp determined by the second terminal based on its local clock; the method may further include: determining the time offset between the local clock of the first terminal and the local clock of the second terminal.

[0103] Determining whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference may include: determining the difference between the first timestamp and the second timestamp based on the time offset; and determining whether the difference is less than or equal to a preset difference.

[0104] The local clock can represent an internal timer provided by the terminal's operating system, with millisecond-level accuracy, but deviations may exist between different terminals. The time offset represents the time difference between the local clocks of the first and second terminals. For example, if the clock of the first terminal is 80ms ahead of the clock of the second terminal, the time offset is positive 80ms. This offset can be estimated in advance through methods such as Bluetooth broadcasting time information exchange or NTP synchronization. After determining the time offset, the first or second timestamp can be adjusted based on this offset, and then the difference between the timestamps can be calculated, thus improving the accuracy of detection.

[0105] Assume the time offset between the first terminal and the second terminal is M, which can be positive or negative. Here, we assume the first terminal is ahead of the second terminal, and the time offset M is positive. When calculating the difference between the first and second timestamps, the first terminal can subtract the time offset M from the first timestamp and then subtract it from the second timestamp; alternatively, it can add the second timestamp to the time offset M and then subtract it from the first timestamp. This allows us to obtain the relative time difference after eliminating clock skew, more accurately reflecting the synchronization of the collision event.

[0106] In practical applications, the time offset between terminals can be determined through methods such as Bluetooth broadcasting. For example, the first terminal broadcasts its local time T11 via Bluetooth; after receiving it, the second terminal can receive the broadcast time T12 based on its local time record and send it back; after receiving the reply, the first terminal receives the reply time T13 based on its local time record; both parties calculate the offset offset = [(T12-T11) + (T12-T13)] / 2 according to the bidirectional communication model.

[0107] Alternatively, the offset can be determined by a simplified evaluation method, such as offset≈T12-T11-estimated transmission delay.

[0108] In one embodiment of this specification, by pre-determining the time offset between the local clocks of the first terminal and the second terminal, and compensating for the offset when verifying the collision timestamp, the calculation result of the time difference more accurately reflects the synchronization of the actions of the first terminal and the second terminal; effectively overcoming the misjudgment problem caused by differences in terminal hardware clocks or system clock drift, and significantly improving the robustness and reliability of collision recognition.

[0109] To ensure users can successfully access the content of the business page, they can be prompted to enable certain functions before displaying the target page. Optionally, in one embodiment of this specification, the method before the first terminal displays the target page may further include: determining whether the first terminal has enabled preset function permissions; the preset function permissions include at least one of Bluetooth, NFC, and location positioning; if the first terminal has not enabled the preset function permissions, a prompt page is displayed to prompt the user to enable the preset function permissions; if the first terminal has enabled the preset function permissions, the target page is displayed.

[0110] In practical applications, before displaying the target page for triggering the tap-to-win service, it is advisable to check whether the terminal has enabled the necessary system function permissions (such as Bluetooth, NFC, location positioning, etc.). If not, guide the user to the settings page or display a prompt to ensure that the hardware and system capabilities required for subsequent interactions are available.

[0111] The preset function permissions can represent the operating system-level hardware or service switches on which the business processing method provided in at least one embodiment of this specification depends for normal operation. Examples include Bluetooth, NFC, and location services.

[0112] In practical applications, terminal applications can query the global enabling status of corresponding functions through system APIs. If a function is not enabled, a prompt page can be displayed, prompting the user to enable the corresponding function. This prompt page can also include a control for navigating to the permission settings page; if the user clicks this control, the terminal can navigate to the settings page. If the terminal has already enabled the preset function permissions, it can display the target page.

[0113] If a user performs an operation on a page that allows redirection to the target page, the terminal application, upon receiving this operation, can check whether the terminal has enabled the preset function permission. If not, the terminal can display a prompt page; if enabled, it can display the target page. The prompt page can be a standalone page, or it can be a pop-up window, notification message, etc.

[0114] In one embodiment of this specification, by actively detecting preset function permissions such as Bluetooth, NFC, and location positioning before displaying the target page, and guiding the user to complete the configuration when the permissions are not enabled, the core interaction process is effectively avoided from being interrupted or failed due to the lack of system functions; the guidance of user operation is significantly improved, invalid entry and user confusion are reduced, and the subsequent collision detection based on sensors and short-range communication can be reliably executed with full hardware support.

[0115] To facilitate users in using the terminal's NFC function to handle other services, optionally, the method in one embodiment of this specification may further include: if the first terminal exits the target page or the service page, then the near-field communication function of the first terminal is restored to a non-silent state; the first terminal in the non-silent state is able to send or respond to near-field communication signals.

[0116] In practical applications, when a user exits the target page or business page, the terminal can actively deactivate the NFC silent state that was previously set to avoid interference, allowing the NFC module to return to its normal working mode of sending or responding to near-field communication signals, thereby ensuring that the user can use NFC functions normally in other scenarios (such as payment, access control, public transport cards, etc.).

[0117] Exit can mean that the user actively returns, closes the application, switches to the background, or the page is destroyed, causing the front end to no longer display the business page or target page.

[0118] The non-silent state indicates that the NFC module has returned to normal working mode, such as actively sending polling signals (Polling for Type A / B tags); responding to external card reader requests (such as POS machines and access control systems); and enabling card emulation functions.

[0119] In one embodiment of this specification, by restoring the near-field communication function from a silent state to a non-silent state after the user exits the target page or business page, it is ensured that the NFC module can still support daily functions such as payment, access control, and transportation cards normally in non-interactive scenarios. This effectively avoids system-level service interruptions caused by temporary function suppression and improves application compatibility and user trust.

[0120] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0121] According to the above explanation, Figure 3 This is a swimlane diagram illustrating a business processing method provided in one embodiment of this specification. The method may include four stages. The first stage involves the first and second terminals displaying the target page, entering NFC silent mode, and then initiating motion detection monitoring and Bluetooth scanning. The second stage involves time synchronization between the first and second terminals. This synchronization process can begin after the target page is displayed, or it can occur after Bluetooth is enabled on both terminals. The third stage involves a collision detection. Both the first and second terminals can determine whether a collision event has occurred according to preset collision detection rules or models. Assuming a collision is detected when the first and second terminals bump into each other, the first terminal can record the first timestamp T1 of the collision and generate a collision detection request based on this timestamp, which is then sent to the second terminal. The second terminal can record a second timestamp T2 of the collision. After receiving a detection request from the first terminal, it can perform collision detection verification to determine whether the difference between the first and second timestamps is less than or equal to a preset difference, such as 100ms. If the difference is less than or equal to the preset difference, the second terminal can send a valid collision confirmation message to the first terminal. This allows the first terminal to confirm that a collision has occurred with the second terminal. Fourth stage: After confirming a collision between the first and second terminals, the first terminal can establish a communication link with the second terminal, such as establishing a Bluetooth or Wi-Fi connection. The first and second terminals can then transmit data through this link, such as exchanging electronic business cards, transferring files, or audio / video. Alternatively, the first and / or second terminal can send a business data retrieval request to the server, and the server can provide corresponding business information back to the first and / or second terminals. The first and second terminals can execute these stages synchronously or asynchronously.

[0122] Based on the same idea, embodiments of this specification also provide apparatus corresponding to the above methods.

[0123] Figure 4 This is a schematic diagram of a business processing apparatus provided in one embodiment of this specification.

[0124] like Figure 4 As shown, the device may include: The state switching module 402 is used to switch the near-field communication function of the first terminal to a silent state after the first terminal displays the target page; the first terminal in the silent state does not send or respond to near-field communication signals. The data acquisition module 404 is used to acquire sensor data collected by the sensor of the first terminal; The collision determination module 406 is used to determine whether a collision event has occurred at the first terminal based on the sensor data. The terminal determination module 408 is used to determine whether there is a second terminal that collides with the first terminal; The page display module 410 is used to display a service page on the first terminal if a collision event occurs on the first terminal and there is a second terminal that collides with the first terminal.

[0125] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0126] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0127] The above is a schematic diagram of a service processing apparatus according to this embodiment. It should be noted that the technical solution of this service processing apparatus and the technical solution of the aforementioned service processing method belong to the same concept. Details not described in detail in the technical solution of the service processing apparatus can be found in the description of the technical solution of the aforementioned service processing method. This apparatus can serve as a first terminal or as a component within a first terminal.

[0128] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0129] Figure 5 A structural block diagram of a computing device 500 provided according to an embodiment of this specification is shown.

[0130] The computing device 500 includes: Memory 510 and processor 520; The memory 510 is used to store computer programs / instructions, and the processor 520 is used to execute the computer programs / instructions, which, when executed by the processor 520, implement the steps of the above method.

[0131] Specifically, the components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and the database 550 is used to store data.

[0132] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0133] In one embodiment of this specification, the aforementioned components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0134] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 500 can also be a mobile or stationary server.

[0135] The processor 520 implements the steps of the above method when executing the computer instructions.

[0136] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the task processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the task processing method described above.

[0137] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the task processing method as described above.

[0138] The above is an illustrative embodiment of a computer-readable storage medium. It should be noted that the technical solution of this storage medium and the technical solution of the task processing method described above belong to the same concept. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the task processing method described above.

[0139] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the task processing method described above.

[0140] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the task processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the task processing method described above.

[0141] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of apparatus and device, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, device and method provided in the embodiments of this specification are corresponding to each other, and therefore the apparatus and device also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0142] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0143] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0144] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0145] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0146] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0147] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0148] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0149] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0150] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0151] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0152] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0153] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0154] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0155] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for business processing, comprising: After the target page is displayed on the first terminal, the near-field communication function of the first terminal is switched to silent mode; The first terminal in the silent state does not send or respond to near-field communication signals; Obtain sensor data collected by the sensors of the first terminal; Based on the sensor data, determine whether a collision event has occurred at the first terminal; Determine whether there is a second terminal that collides with the first terminal; If a collision event occurs on the first terminal and there is a second terminal that also collides with the first terminal, then the first terminal displays the service page.

2. The method according to claim 1, further comprising: If a collision event occurs at the first terminal, then the first timestamp of the collision event is determined. The first timestamp is sent via short-range communication. The determination of whether there is a second terminal that collides with the first terminal includes: Determine whether collision confirmation information sent by the second terminal via short-range communication is obtained within a first preset time period; the collision confirmation information is generated by the second terminal after the difference between the second timestamp of the second terminal determining that a collision event has occurred and the first timestamp of the first terminal obtained is less than or equal to a preset difference. If a collision confirmation message is received from the second terminal via short-range communication within the first preset time period, it is determined that a second terminal has collided with the first terminal.

3. The method according to claim 1, further comprising: If a collision event occurs at the first terminal, then the first timestamp of the collision event is determined. The first timestamp is sent via short-range communication. The determination of whether there is a second terminal that collides with the first terminal includes: Determine whether a second timestamp sent by the second terminal via short-range communication is obtained within a second preset time period; the second timestamp is the timestamp of the collision event that occurred on the second terminal. If the second timestamp is obtained, determine whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference; If the difference between the first timestamp and the second timestamp is less than or equal to a preset difference, then it is determined that there is a second terminal that collides with the first terminal.

4. The method according to claim 3, further comprising: If the difference between the first timestamp and the second timestamp is less than or equal to a preset difference, then a collision confirmation message is sent via short-range communication. The collision confirmation information is used to indicate that the first terminal and the second terminal have collided.

5. The method according to claim 1, further comprising: If a collision event occurs at the first terminal, the first timestamp of the collision event is determined. Obtain the second timestamp sent by the second terminal via short-range communication; The second timestamp is the timestamp of the collision event that occurred on the second terminal; The determination of whether there is a second terminal that collides with the first terminal includes: Determine whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference; If the difference between the first timestamp and the second timestamp is less than or equal to a preset difference, then it is determined that there is a second terminal that collides with the first terminal.

6. The method according to claim 1, wherein if a second terminal collides with the first terminal, the first terminal displays a service page, comprising: If a second terminal collides with the first terminal, the first terminal sends a result message indicating that a collision has occurred to the server. Based on the result information, the server feeds back business information to the first terminal; The first terminal displays a service page based on the service information.

7. The method according to claim 1, wherein if a second terminal collides with the first terminal, the first terminal displays a service page, comprising: If a second terminal collides with the first terminal, the first terminal sends service data to the second terminal via short-range communication, or receives service data sent by the second terminal via short-range communication. Based on the aforementioned business data, the business page is displayed.

8. The method according to claim 1, wherein if a collision event occurs at the first terminal, determining whether there is a second terminal that collides with the first terminal includes: If a collision event occurs at the first terminal, the first timestamp of the collision event is sent to the server. Based on the first timestamp, the server determines whether there is a second terminal that collides with the first terminal; the second terminal that collides with the first terminal is a terminal whose distance from the first terminal is less than or equal to a preset distance and whose difference between the provided second timestamp and the first timestamp is less than or equal to a preset difference. If a second terminal collides with the first terminal, then service data is sent to the first terminal; The first terminal displays a service page based on the service data.

9. The method according to claim 1, wherein the sensor data includes acceleration data and / or motion direction data of the first terminal in at least one of the horizontal, vertical and depth directions; The step of determining whether a collision event has occurred at the first terminal includes: Determine whether the sensor data meets preset characteristics; If the preset characteristics are met, it is determined that a collision event has occurred at the first terminal; The preset features include at least one of the following features: The acceleration data represents an acceleration value that is greater than or equal to a preset threshold. The acceleration data shows an initial increase followed by a decrease within a preset time window, with the peak width being less than or equal to the preset peak width. The first terminal changes its direction of motion in at least two of the horizontal, vertical and depth directions by an amount greater than or equal to a preset amount.

10. The method according to claim 1, wherein determining whether a collision event has occurred at the first terminal includes: The sensor data is then provided to the collision event assessment model. The collision event evaluation model is a pre-trained lightweight machine model; The evaluation results generated by the collision event evaluation model are obtained; the evaluation results are either an evaluation result indicating that a collision event has been sent or an evaluation result indicating that no collision event has occurred.

11. The method according to claim 2 or 3, further comprising, before determining the first timestamp of the collision event,: Synchronize the time between the first terminal and the second terminal so that the first terminal and the second terminal have the same reference time; The determination of the first timestamp of the collision event includes: Based on the aforementioned reference time, the first timestamp of the collision event is determined.

12. The method according to claim 2 or 3, wherein the first timestamp is a timestamp determined by the first terminal based on a local clock, and the second timestamp is a timestamp determined by the second terminal based on a local clock; The method further includes: Determine the time offset between the local clock of the first terminal and the local clock of the second terminal; The step of determining whether the difference between the first timestamp and the second timestamp is less than or equal to a preset difference includes: Based on the time offset, the difference between the first timestamp and the second timestamp is determined; Determine whether the difference is less than or equal to a preset difference.

13. The method according to claim 1, further comprising, before the first terminal displays the target page: Determine whether the first terminal has enabled preset function permissions; The preset function permissions include at least one of Bluetooth, NFC near field communication, and location positioning. If the first terminal has not enabled the preset function permissions, a prompt page will be displayed to prompt the user to enable the preset function permissions; If the first terminal has enabled the preset function permissions, then the target page will be displayed.

14. The method according to claim 1, wherein if the first terminal exits the target page or the service page, the near-field communication function of the first terminal is restored to a non-silent state; the first terminal in the non-silent state is able to send or respond to near-field communication signals.

15. The method according to claim 1, wherein the business page includes at least one of a virtual resource acquisition or sending page, a file transfer page, an information sharing page, and an add friend page.

16. The method according to any one of claims 2, 3, 4, 5, and 7, wherein the short-range communication includes at least one of Bluetooth communication, Wi-Fi Direct, and Ultra-Wideband (UWB) communication.

17. An apparatus for processing business data, comprising: The state switching module is used to switch the near-field communication function of the first terminal to a silent state after the target page is displayed on the first terminal. The first terminal in the silent state does not send or respond to near-field communication signals; The data acquisition module is used to acquire sensor data collected by the sensors of the first terminal; The collision detection module is used to determine whether a collision event has occurred at the first terminal based on the sensor data. The terminal determination module is used to determine whether there is a second terminal that collides with the first terminal; The page display module is used to display a service page on the first terminal if a collision event occurs on the first terminal and a second terminal collides with the first terminal.

18. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 16.

19. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 16.

20. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 16.

Images