Near field file transmission method, device and equipment across systems, and medium

Abstract

The application relates to the technical field of cloud transmission, and discloses a cross-system near-field file transmission method, device, equipment and medium. The method comprises the following steps: judging whether a first communication device and a second communication device belong to the same type of operating system according to first communication characteristic information of the first communication device and second communication characteristic information of the second communication device; when the first communication device and the second communication device do not belong to the same type of operating system, constructing an intermediate communication link according to the first communication characteristic information and the second communication characteristic information; generating a temporary anonymous session identifier on the intermediate communication link according to the first communication characteristic information and the second communication characteristic information; and realizing file transmission in a near-field communication range through a temporary transmission session constructed by the first communication device and the second communication device through the temporary anonymous session identifier. Through the system identification, link construction and session identifier generation of the communication device, the efficiency and safety of cross-system near-field file transmission can be improved.

Description

Technical Field

[0001] This invention relates to the field of cloud transmission technology, and in particular to a method, apparatus, device and medium for near-field file transmission between systems. Background Technology

[0002] With the rapid development of IoT technology, near-field communication (NFC, Bluetooth, Wi-Fi Direct, etc.) has become an important means of file transfer between devices. In daily use, users often need to quickly exchange files such as photos, documents, and contacts between different devices, such as sharing photos between different brands of mobile phones or transferring work files between mobile phones and computers.

[0003] However, most existing near-field file transfer solutions are designed based on the same operating system or ecosystem. When users need to transfer files between devices with different operating systems (such as Android and iOS devices, or Windows and Android devices), they often face numerous limitations. For example, different operating systems use different communication protocols and rules, meaning there is a lack of a unified near-field communication standard between devices with different operating systems. This prevents devices from establishing communication connections, and users typically need to use third-party applications as intermediaries to complete file transfers. This makes the file transfer process cumbersome and fails to achieve secure and efficient cross-system near-field file transfer while ensuring privacy.

[0004] Therefore, how to implement a cross-system near-field file transfer method to improve the efficiency and security of cross-system near-field file transfer has become an urgent problem to be solved. Summary of the Invention

[0005] This invention provides a method, apparatus, device, and medium for cross-system near-field file transfer, the main purpose of which is to solve the problem that related technologies cannot improve the efficiency and security of cross-system near-field file transfer.

[0006] To achieve the above objectives, the present invention provides a near-field file transfer method based on cross-system communication, comprising: Collect first communication characteristic information of the first communication device and second communication characteristic information of the second communication device; Determine whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information. When they do not belong to the same operating system type, an intermediate communication link for cross-system near-field communication is constructed between the first communication device and the second communication device based on the first communication feature information and the second communication feature information. On the intermediate communication link, a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device is generated based on the first communication feature information and the second communication feature information. A temporary transmission session is constructed based on the temporary anonymous session identifier, and the first communication device and the second communication device transfer files within a preset near-field communication range through the temporary transmission session.

[0007] The present invention also provides a near-field file transfer device based on cross-system communication, the device comprising: A communication feature acquisition module is used to acquire first communication feature information of a first communication device and second communication feature information of a second communication device. The system type identification module is used to determine whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information. The communication link construction module is used to construct an intermediate communication link between the first communication device and the second communication device for cross-system near-field communication when they do not belong to the same operating system type, based on the first communication feature information and the second communication feature information. The session identifier generation module is used to generate a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link. The file near-field transmission module is used to construct a temporary transmission session based on a temporary anonymous session identifier. The first communication device and the second communication device realize file transmission within a preset near-field communication range through the temporary transmission session.

[0008] The present invention also provides an electronic device, the electronic device comprising: At least one processor; and, A memory that is communicatively connected to at least one processor; wherein, The memory stores a computer program that can be executed by at least one processor, such that the at least one processor can perform the aforementioned near-field file transfer method based on cross-system communication.

[0009] The present invention also provides a computer-readable storage medium storing at least one computer program, which is executed by a processor in an electronic device to implement the above-described near-field file transfer method based on cross-system communication.

[0010] In this embodiment of the invention, by collecting and comparing the communication feature information of both parties to determine the operating system type, lightweight and low-overhead heterogeneous device identification can be achieved before the link is established. When it is determined that the communication devices belong to different operating systems, an intermediate communication link is adaptively constructed, which can establish a direct connection channel between different heterogeneous terminals, significantly reducing the deployment cost and access threshold of cross-system near-field communication, and avoiding compatibility errors caused by system differences. On the intermediate link, a temporary anonymous session identifier is generated based on the communication feature information of both parties and a temporary transmission session is constructed, which can effectively prevent the transmission link from being tracked or the session from being replayed, enhance the privacy protection capability of the file transmission process, and improve the efficiency and security of cross-system near-field file transmission.

[0011] Therefore, the method, apparatus, device and medium for cross-system near-field file transfer proposed in this invention can solve the problems of insufficient efficiency and security in cross-system near-field file transfer in the prior art. Attached Figure Description

[0012] Figure 1 A flowchart illustrating a near-field file transfer method across systems provided in an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating the process of establishing a communication link in a near-field file transfer method across systems, provided in an embodiment of the present invention. Figure 3 This is a schematic diagram illustrating the process of session identifier generation in a near-field file transfer method based on cross-system communication according to an embodiment of the present invention; Figure 4 This is a functional block diagram of a near-field file transfer device based on cross-system communication provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of an electronic device that implements a near-field file transfer method between systems, according to an embodiment of the present invention.

[0013] The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0014] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0015] To address the problem that existing methods cannot improve the efficiency and security of cross-system near-field file transfer, one embodiment of the present invention provides a cross-system near-field file transfer method, which is a cross-system near-field file transfer method based on data analysis technology.

[0016] Reference Figure 1The diagram shown is a flowchart illustrating a near-field file transfer method based on cross-system communication provided in an embodiment of this application. In this embodiment, the near-field file transfer method based on cross-system communication includes: S1. Collect the first communication characteristic information of the first communication device and the second communication characteristic information of the second communication device.

[0017] In this embodiment of the invention, the first communication feature information and the second communication feature information refer to a set of parameters or data that can reflect the identity attributes, protocol capabilities, hardware performance and current communication status of the first communication device and the second communication device in a near-field communication scenario.

[0018] In this embodiment of the invention, the first communication device sends a feature information request to the second communication device through the Bluetooth Low Energy Broadcast channel, and receives the second communication feature information returned by the second communication device in response to the feature information request. At the same time, the first communication device reads the first communication feature information from the local system configuration. The first or second communication feature information includes, but is not limited to, operating system fingerprint features, device capability parameter set, and near-field communication protocol stack set, such as device name, operating system type, supported Bluetooth Profile list, and bandwidth.

[0019] S2. Determine whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information.

[0020] In this embodiment of the invention, the first operating system type identifier and the second operating system type identifier of the first communication device and the second communication device are identified according to the first communication feature information and the second communication feature information, respectively. It is then determined whether the first operating system type identifier and the second operating system type identifier are the same, thereby determining whether the first communication device and the second communication device belong to the same operating system type.

[0021] In this embodiment of the invention, determining whether a first communication device and a second communication device belong to the same operating system type based on first communication feature information and second communication feature information includes: extracting a first operating system fingerprint feature of the first communication device from the first communication feature information, and extracting a second operating system fingerprint feature of the second communication device from the second communication feature information; calculating the similarity between the first operating system fingerprint feature and the second operating system fingerprint feature and each candidate operating system fingerprint template in a preset operating system feature library, respectively, to obtain a first similarity set and a second similarity set; selecting the candidate operating system fingerprint template with the highest similarity in the first similarity set as the first operating system fingerprint template, and obtaining a first operating system type identifier of the first communication device based on the first operating system fingerprint template; selecting the candidate operating system fingerprint template with the highest similarity in the second similarity set as the second operating system fingerprint template, and obtaining a second operating system type identifier of the second communication device based on the second operating system fingerprint template; when the first operating system type identifier and the second operating system type identifier are the same, determining that the first communication device and the second communication device belong to the same operating system type; when the first operating system type identifier and the second operating system type identifier are different, determining that the first communication device and the second communication device do not belong to the same operating system type.

[0022] In this embodiment of the invention, operating system fingerprint features, such as OS type (Android / iOS), system version number, etc., are used to determine whether the first communication device and the second communication device are of the same OS type. Specifically, the first operating system fingerprint feature of the first communication device is extracted from the first communication feature information, and the second operating system fingerprint feature of the second communication device is extracted from the second communication feature information.

[0023] In detail, within a pre-defined operating system feature library, each candidate operating system fingerprint template represents a typical performance of a known operating system at the communication layer. The fingerprint features of the first and second operating systems are compared one by one with each candidate operating system fingerprint template, i.e., the similarity between them is calculated. Common similarity metrics include cosine similarity and inverse Euclidean distance. A complete comparison is performed on the first communication device to obtain a first similarity set between the first communication device and all candidate operating system fingerprint templates. The same process is performed on the second communication device to obtain a second similarity set. The first and second similarity sets respectively reflect which operating systems the first and second communication devices are most likely to correspond to.

[0024] Specifically, in the first similarity set, the candidate operating system fingerprint template with the highest similarity means that the communication fingerprint of the first communication device is most consistent with the operating system represented by the candidate operating system fingerprint template. Therefore, it is selected as the first operating system fingerprint template of the first communication device. After the first operating system fingerprint template is selected, the template in the operating system feature library contains the type identifier of the operating system. Through the mapping relationship between the template and the type identifier, the type identifier of the operating system currently running by the first communication device can be deduced.

[0025] The step of selecting the candidate operating system fingerprint template with the highest similarity in the second similarity set as the second operating system fingerprint template and obtaining the second operating system type identifier of the second communication device based on the second operating system fingerprint template is the same as the step of selecting the candidate operating system fingerprint template with the highest similarity in the first similarity set as the first operating system fingerprint template and obtaining the first operating system type identifier of the first communication device based on the first operating system fingerprint template, and will not be repeated here.

[0026] Furthermore, the first operating system type identifier of the first communication device is directly compared with the second operating system type identifier of the second communication device: if the two are completely identical, it is determined that the first communication device and the second communication device belong to the same operating system type; if there is any difference between the two, it is determined that the first communication device and the second communication device do not belong to the same operating system type.

[0027] In this embodiment of the invention, the determination of whether two communication devices belong to the same operating system type is based on the first communication feature information and the second communication feature information. Without relying on deep protocol parsing or plaintext authentication, lightweight and low-overhead operating system type consistency detection can be achieved at the network layer or transport layer.

[0028] S3. When they belong to the same operating system type, the first communication device and the second communication device realize file transfer within the preset near-field communication range through the preset file transfer protocol.

[0029] In this embodiment of the invention, the preset file transfer protocol refers to a set of file transfer communication rules that are pre-fixed or configured in the operating systems of the first and second communication devices. Different operating system types correspond to different default protocol configuration schemes.

[0030] For Unix-like operating system environments, the operating system typically pre-configures the NFS network file system protocol, which is designed to support direct access to file systems on various Unix systems. For Windows operating system environments, the operating system pre-configures the SMB network file system protocol, which is specifically designed for the file system access needs of Windows operating systems. When the first and second communication devices are determined to be of the same operating system type, the communication module automatically loads the corresponding protocol stack, including transport layer protocols (such as TCP or UDP), application layer protocol formats, data fragmentation and reassembly rules, error detection and retransmission mechanisms, and other components, to ensure that both communicating parties can use the same protocol rules for file transfer immediately after the connection is established.

[0031] Specifically, near-field communication uses short-range high-frequency wireless communication technology and relies on electromagnetic field induction to achieve contactless point-to-point data transmission. That is, communication devices establish a communication connection through physical proximity. This process does not require users to manually search and pair. During the establishment of the communication connection, the communication devices complete device security authentication through a specific request-response sequence to ensure that the first and second communication devices can transfer files within a preset near-field communication range through a preset file transfer protocol.

[0032] Among them, the effective file transmission distance of near-field communication is limited by the physical contact range. This transmission distance characteristic ensures the security of data transmission and avoids remote illegal eavesdropping. The communication device continuously monitors the status of the communication link within the effective range. Once the transmission distance is detected to exceed the preset distance threshold, the transmission session is automatically terminated and communication resources are released to ensure the security of the communication process.

[0033] S4. When they do not belong to the same operating system type, construct an intermediate communication link between the first communication device and the second communication device for cross-system near-field communication based on the first communication characteristic information and the second communication characteristic information.

[0034] In this embodiment of the invention, cross-system near-field communication refers to the use of short-range wireless transmission technologies such as Bluetooth, Wi-Fi Direct, NFC, and hotspot relay between terminal devices with different operating systems (such as Android and iOS, Linux and Windows) to achieve file transfer; the intermediate communication link refers to the logical or physical transmission channel established to connect the first communication device and the second communication device, so that both parties can complete near-field file communication with a unified data format and interaction process.

[0035] like Figure 2As shown, in this embodiment of the invention, constructing an intermediate communication link between a first communication device and a second communication device for cross-system near-field communication based on first communication feature information and second communication feature information includes: S21, determining a subset of common protocols commonly supported by the first and second communication devices based on the first and second communication feature information; S22, extracting a first set of device capability parameters for the first communication device from the first communication feature information, and extracting a second set of device capability parameters for the second communication device from the second communication feature information; S23, generating first device capability constraints for the first communication device based on the first set of device capability parameters, and generating second device capability constraints for the second communication device based on the second set of device capability parameters; S24, selecting a target communication protocol from the subset of common protocols that satisfies both the first and second device capability constraints; S25, initiating a link negotiation request from the first communication device to the second communication device based on the handshake specification of the target communication protocol; S26, after the second communication device confirms acceptance of the link negotiation request, establishing an intermediate communication link between the first and second communication devices for cross-system near-field communication.

[0036] In this embodiment of the invention, a first set of near-field communication protocol stacks supported by a first communication device is extracted from the first communication feature information, and a second set of near-field communication protocol stacks supported by a second communication device is extracted from the second communication feature information. The first and second sets of near-field communication protocol stacks are compared item by item using protocol feature matching technology to identify protocol entries that exist in both sets simultaneously. This forms a common protocol range that both sets have basic support capabilities, i.e., a common protocol subset. This ensures that subsequent link construction has the most basic protocol compatibility prerequisite and avoids cross-system communication failure due to protocol incompatibility.

[0037] In detail, a first set of device capability parameters for the first communication device is extracted from the first communication feature information, and a second set of device capability parameters for the second communication device is extracted from the second communication feature information. The device capability parameter sets include maximum transmission rate, supported frequency band range, buffer capacity, and maximum concurrent connection limit, etc. The extracted device capability parameter sets are transformed into a set of logical constraint expressions to describe the capability boundaries that the communication device must meet during communication. For example, if a communication device has a limited maximum transmission rate, the constraint conditions will reflect the limitation on the upper limit of the transmission rate; if a device does not support a certain encryption method, the constraint conditions will exclude protocol options involving that encryption method. Specifically, first device capability constraints are generated for the first communication device, and second device capability constraints are generated for the second device, so that subsequent protocol screening can automatically exclude options that exceed the device's capability range.

[0038] Furthermore, using a subset of common protocols as a candidate pool and employing both first and second device capability constraints as dual filtering conditions, each protocol in the candidate pool is examined one by one. Only a protocol that does not violate the capability boundaries of either the first or second communication device is retained as a valid candidate. If multiple protocols meet the conditions, the final target communication protocol can be selected based on a priority strategy. This screening process ensures that the selected protocol is technically feasible for both parties, avoiding link establishment failures caused by protocol requirements exceeding the capabilities of either party.

[0039] Furthermore, each communication protocol defines a standardized handshake process before establishing a connection, used by both parties to confirm their communication intentions, negotiate communication parameters, and synchronize states. The first communication device, as the initiator, constructs a link negotiation request message according to the handshake specifications defined by the target communication protocol and sends it to the second communication device. This link negotiation request message carries the communication parameter configuration that the first communication device wishes to use; essentially, it is a formal request to the second communication device to establish a connection according to these rules, ensuring that the format and semantics of the negotiation request can be correctly responded to by the second communication device.

[0040] When the second communication device receives the link negotiation request, it parses the parameters in the link negotiation request and verifies them against its own capabilities. If it confirms that it can meet the parameter requirements in the link negotiation request, it returns an acknowledgment response message according to the handshake specification of the target communication protocol.

[0041] Specifically, after the first communication device receives the confirmation response message, the first communication device and the second communication device complete the entire handshake process, and the intermediate communication link officially enters the active state, enabling the first communication device and the second communication device to achieve file transfer within the near field range in cross-system scenarios.

[0042] In this embodiment of the invention, determining a subset of common protocols jointly supported by the first communication device and the second communication device based on the first communication feature information and the second communication feature information includes: extracting a set of first near-field communication protocol stacks supported by the first communication device from the first communication feature information; extracting a set of second near-field communication protocol stacks supported by the second communication device from the second communication feature information; and performing an intersection operation on the first near-field communication protocol stack set and the second near-field communication protocol stack set to determine the subset of common protocols jointly supported by the first communication device and the second communication device.

[0043] In this embodiment of the invention, the first communication feature information records all the protocol capabilities exposed by the first communication device in the near-field communication scenario. By scanning the first communication feature information layer by layer, the protocols declared and supported by the first communication device at each layer are identified and collected one by one, and finally summarized into a set containing all the near-field communication protocol capabilities of the first communication device, namely the first near-field communication protocol stack set. The extraction method of the second near-field communication protocol stack set is the same as that of the first near-field communication protocol stack set, and will not be described in detail here.

[0044] Specifically, each protocol in the first near-field communication protocol stack set is traversed, and each protocol is checked to see if it also exists in the second near-field communication protocol stack set. If it exists, it is retained; otherwise, it is discarded, to ensure that no protocol that exists only on one side is introduced. After comparison and filtering, the protocols that are ultimately retained are those supported by both the first and second communication devices, thus forming a common protocol subset.

[0045] In this embodiment of the invention, a direct transmission channel is dynamically established between heterogeneous devices by means of communication feature information, which can reduce the access threshold and deployment cost of cross-system near-field communication, thereby avoiding compatibility errors caused by system differences.

[0046] S5. Generate a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link.

[0047] In this embodiment of the invention, the temporary anonymous session identifier is a unique identity marker that is dynamically generated for a near-field file transfer task and is only valid within the lifecycle of the current communication link. The temporary anonymous session identifier does not contain traceable information such as device hardware information or user identity information. It is used to distinguish different transmission sessions on the intermediate communication link and associate the data streams sent and received by the two communication devices. It becomes invalid and discarded after the transmission is completed, so as to ensure the privacy and tracelessness of the transmission process.

[0048] In this embodiment of the invention, generating a temporary anonymous session identifier for near-field file transfer between a first communication device and a second communication device based on first and second communication feature information on an intermediate communication link includes: acquiring multiple available communication paths on the intermediate communication link; performing path decision-making on the multiple available communication paths to obtain a target communication path; acquiring a first timestamp when collecting the first communication feature information and a second timestamp when collecting the second communication feature information, and determining a common reference timestamp based on the first and second timestamps; generating a random salt value using a preset random number generator; combining the common reference timestamp and the random salt value according to a preset concatenation order to obtain a fused string; performing a first round of hash operation on the fused string using a preset first hash algorithm to obtain a first hash value, and performing a second round of hash operation on the fused string using a preset second hash algorithm to obtain a second hash value; performing a bitwise XOR operation on the high-order part of the first hash value and the low-order part of the second hash value, and performing a bitwise AND operation on the XOR result with a preset fixed mask to obtain a temporary anonymous session identifier for near-field file transfer between the first and second communication devices.

[0049] In this embodiment of the invention, after the intermediate communication link is established, since there may be multiple physically or logically reachable communication paths in the near-field communication environment, such as radio frequency channels of different frequency bands or different near-field communication protocol channels, all available communication paths are enumerated. Based on a preset path decision strategy, each available communication path is comprehensively evaluated. The evaluation dimensions include the expected bandwidth, channel stability coefficient, and expected transmission power consumption of the available communication path. By calculating the path quality characteristic value of each available communication path under each evaluation dimension, the available communication path with the largest path quality characteristic value is selected as the target communication path. Subsequently, the generation and transmission of the temporary anonymous session identifier are performed on this target communication path, ensuring that the transmission process of the temporary anonymous session identifier itself also has optimal reliability, avoiding loss or damage of the identifier during transmission due to poor path quality.

[0050] Specifically, when collecting the first communication feature information and the second communication feature information, the collection time of each is recorded, namely the first timestamp and the second timestamp. Since the two collections occur at different times, neither timestamp can be used to represent the state of both parties at the same time. Usually, the later time between the first timestamp and the second timestamp is taken, or the middle time between the first timestamp and the second timestamp is taken as a common reference timestamp.

[0051] In detail, the random salt value is generated by a pre-defined random number generator according to cryptographic security standards. Its core function is to inject unpredictable randomness into the temporary anonymous session identifier, preventing attackers from guessing the temporary anonymous session identifier by exhaustively counting timestamps. Specifically, the public reference timestamp and the random salt value are combined in a pre-agreed concatenation order, such as placing the public reference timestamp first and the random salt value last, to form a fused string that integrates deterministic time information and random salt value information.

[0052] Furthermore, two different hash algorithms are used to perform independent hash operations on the same fused string, yielding a first hash value and a second hash value. The purpose of using two different hash algorithms, rather than performing the operation twice, is to increase the degree of confusion in the hash operation. Even if one hash algorithm has a known collision vulnerability, the introduction of the other hash algorithm can effectively compensate for this deficiency, thereby significantly improving the collision resistance and irreversibility of the final temporary anonymous session identifier.

[0053] Furthermore, the high-order bits are extracted from the first hash value and the low-order bits are extracted from the second hash value. A bitwise XOR operation is then performed on the high-order and low-order bits, i.e., the same bits result in zero and different bits result in one. This operation cross-integrates the information of the first and second hash values, so that the final XOR result inherits the output characteristics of both hash algorithms. The result of the XOR operation is then bitwise ANDed with a preset fixed mask. The fixed mask truncates and normalizes the number of bits in the XOR result, retaining only the valid bits at specified positions in the fixed mask and discarding the rest, thereby constraining the XOR result into a fixed-length bit string, and finally obtaining the temporary anonymous session identifier for near-field file transfer between the first and second communication devices.

[0054] like Figure 3 As shown, in this embodiment of the invention, path decision-making is performed on multiple available communication paths to obtain a target communication path, including: S31, obtaining the near-field file to be transmitted between the first communication device and the second communication device, and calculating the file size of the near-field file; S32, obtaining the channel expected bandwidth, channel stability coefficient, and expected transmission power consumption of each available communication path; S33, configuring a first weighting coefficient corresponding to the channel expected bandwidth, a second weighting coefficient corresponding to the channel stability coefficient, and a third weighting coefficient corresponding to the expected transmission power consumption according to the file size; S34, performing weighted calculation on the channel expected bandwidth, channel stability coefficient, and expected transmission power consumption according to the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient to obtain the path quality feature value of each available communication path; S35, selecting the available communication path with the largest path quality feature value as the target communication path.

[0055] In this embodiment of the invention, the near-field file that needs to be transmitted between the first communication device and the second communication device is obtained, and the byte count of the near-field file is calculated to obtain the file size of the near-field file. Large files have higher requirements for communication bandwidth, while small files are less sensitive to transmission power consumption. Therefore, the file size directly determines how much influence each evaluation dimension should have in the path decision.

[0056] In detail, for each available communication path on the intermediate communication link, key performance indicators are obtained under various evaluation dimensions, namely, channel expected bandwidth, channel stability coefficient, and expected transmission power consumption. Among them, channel expected bandwidth reflects the maximum data throughput that the available communication path can provide in the current network environment; channel stability coefficient reflects the degree of signal quality fluctuation of the available communication path during near-field communication, and the higher the value, the more stable the transmission; expected transmission power consumption reflects the equipment energy required to complete a full transmission on the available communication path.

[0057] Furthermore, based on the file size, corresponding weight coefficients are dynamically configured for the channel's expected bandwidth, channel stability coefficient, and expected transmission power consumption. When the file is large, transmission speed becomes the bottleneck, so the channel's expected bandwidth should receive a higher weight. When the file is small, transmission speed is no longer the primary concern, and more attention should be paid to transmission power consumption, so the weight of expected transmission power consumption should be increased accordingly. The weight of the channel stability coefficient is flexibly adjusted according to the file's sensitivity to transmission reliability, ensuring that the path decision always aligns with the actual needs of the current transmission task, thus avoiding decision-making biases in different scenarios caused by fixed-weight schemes.

[0058] Furthermore, the expected bandwidth, channel stability coefficient, and expected transmission power consumption of each available communication path are multiplied by their corresponding weight coefficients, and then the three product results are summed to obtain the path quality feature value of the available communication path. The higher the path quality feature value, the better the overall performance of the available communication path under the current transmission task.

[0059] Specifically, the available communication path with the largest path quality characteristic value is selected as the target communication path. This target communication path is used as the carrier channel for near-field file transfer, which can achieve the best balance between transmission efficiency, transmission quality and energy consumption control under the current file size conditions. This provides the optimal physical carrier foundation for the subsequent generation of temporary anonymous session identifiers and the actual transmission of files.

[0060] For example, if the size of the near-field file is greater than a preset size threshold (e.g., 50MB), the channel's expected bandwidth weight will be increased, and the available communication path with the highest expected bandwidth and good channel stability will be selected as the target communication path, such as a Wi-Fi hotspot relay or a local area network channel. For example, if the file size of the near-field file is less than or equal to a preset size threshold, and one party's communication device is in low power mode, the expected transmission power consumption will be increased. Subsequently, the available communication paths of the existing LAN channel or WebRTC channel will be reused as the target communication path to avoid selecting high-power Wi-Fi hotspot relay.

[0061] In this embodiment of the invention, a temporary anonymous session identifier is generated on the intermediate communication link based on the communication feature information of both parties, which effectively prevents the transmission link from being tracked or the session from being replayed, strengthens the privacy protection and anti-tracking capability of near-field file transmission, and significantly improves the convenience and security of cross-device transmission in temporary scenarios.

[0062] S6. Construct a temporary transmission session based on the temporary anonymous session identifier, and the first communication device and the second communication device realize file transmission within the preset near-field communication range through the temporary transmission session.

[0063] In this embodiment of the invention, the temporary transmission session is a one-time logical communication channel with a defined session lifecycle established based on a temporary anonymous session identifier, used to carry the actual data stream of near-field file transmission. The near-field communication range refers to the physical distance range within which the first communication device and the second communication device can directly exchange wireless data, typically covering several centimeters to tens of meters (e.g., within 10 centimeters for NFC, 10 to 100 meters for Bluetooth, and tens to hundreds of meters for Wi-Fi Direct). Beyond this near-field communication range, the communication link will be interrupted or the signal strength will be insufficient to maintain an effective transmission rate. File transmission refers to the process of sending near-field files completely and reliably from the first communication device to the second communication device through the communication link. In this invention, it specifically refers to end-to-end direct file transmission based on near-field communication technology.

[0064] In this embodiment of the invention, constructing a temporary transmission session based on a temporary anonymous session identifier includes: generating a session creation request based on the temporary anonymous session identifier; sending the session creation request to a preset session management server, whereby the session management server verifies the validity of the temporary anonymous session identifier and assigns a unique session identifier to the temporary anonymous session identifier that passes the validity verification; creating a temporary session instance on the session management server based on the unique session identifier; and associating and binding the temporary anonymous session identifier with the temporary session instance to obtain a temporary transmission session.

[0065] In this embodiment of the invention, a temporary anonymous session identifier is used as the core credential. The temporary anonymous session identifier is encapsulated into the request message according to the preset session creation request message format, and necessary metadata information, such as request type, time window, and transmission purpose, is attached to obtain the session creation request.

[0066] The session creation request is sent to the preset session management server through the established intermediate communication link. After receiving the session creation request, the session management server assigns a globally unique session identifier to the temporary anonymous session identifier in the session creation request. Its function is to uniquely identify this temporary transmission session in the session management system of the session management server.

[0067] In detail, after assigning a unique session identifier, the session management server creates a temporary session instance in its session management database based on that identifier. This temporary session instance contains all the runtime information required for the current transmission session, such as the session's validity period, allowed transmission behaviors, and associated communication paths. The session management server associates and binds the temporary anonymous session identifier with the temporary session instance, establishing a one-to-one mapping relationship between the two. After binding, the temporary anonymous session identifier becomes the sole entry credential for accessing the temporary session instance, while the temporary session instance becomes the actual runtime carrier for near-field file transmission. This achieves a balance between anonymity and operability in near-field file transmission scenarios, allowing the first and second communication devices to transmit files within a preset near-field communication range through the temporary transmission session.

[0068] In this embodiment of the invention, a temporary transmission session is constructed based on a temporary anonymous session identifier to achieve near-field file transmission, which can effectively reduce the risk of file leakage, realize self-limiting security protection of files during transmission, and significantly improve the efficiency and security of cross-system near-field file transmission.

[0069] like Figure 4 The diagram shown is a functional block diagram of a near-field file transfer device based on cross-system communication provided in an embodiment of the present invention.

[0070] The present invention relates to a near-field file transfer device 400 for inter-system communication, which can be installed in an electronic device. Depending on the functions implemented, the near-field file transfer device 400 may include a communication feature acquisition module 401, a system type identification module 402, a communication link construction module 403, a session identifier generation module 404, and a near-field file transfer module 405. A module in this invention can also be referred to as a unit, which refers to a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, and which are stored in the memory of the electronic device.

[0071] In this embodiment, the functions of each module / unit are as follows: The communication feature acquisition module 401 is used to acquire first communication feature information of the first communication device and second communication feature information of the second communication device. The system type identification module 402 is used to determine whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information. The communication link construction module 403 is used to construct an intermediate communication link between the first communication device and the second communication device for cross-system near-field communication based on the first communication feature information and the second communication feature information when they do not belong to the same operating system type. The session identifier generation module 404 is used to generate a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link. The file near-field transmission module 405 is used to construct a temporary transmission session based on the temporary anonymous session identifier, and the first communication device and the second communication device realize file transmission within a preset near-field communication range through the temporary transmission session.

[0072] In one embodiment, when the system type identification module 402 performs the task of determining whether a first communication device and a second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information, it is configured to: extract the first operating system fingerprint feature of the first communication device from the first communication feature information, and extract the second operating system fingerprint feature of the second communication device from the second communication feature information; calculate the similarity between the first operating system fingerprint feature and the second operating system fingerprint feature and each candidate operating system fingerprint template in a preset operating system feature library, respectively, to obtain a first similarity set and a second similarity set; select the candidate operating system fingerprint template with the highest similarity in the first similarity set as the first operating system fingerprint template, and obtain the first operating system type identifier of the first communication device based on the first operating system fingerprint template; select the candidate operating system fingerprint template with the highest similarity in the second similarity set as the second operating system fingerprint template, and obtain the second operating system type identifier of the second communication device based on the second operating system fingerprint template; when the first operating system type identifier and the second operating system type identifier are the same, determine that the first communication device and the second communication device belong to the same operating system type; when the first operating system type identifier and the second operating system type identifier are different, determine that the first communication device and the second communication device do not belong to the same operating system type.

[0073] In one embodiment, when the communication link construction module 403 constructs an intermediate communication link between a first communication device and a second communication device for cross-system near-field communication based on the first communication feature information and the second communication feature information, it performs the following steps: determining a subset of common protocols commonly supported by the first and second communication devices based on the first and second communication feature information; extracting a set of first device capability parameters of the first communication device from the first communication feature information and extracting a set of second device capability parameters of the second communication device from the second communication feature information; generating first device capability constraints of the first communication device based on the first device capability parameter set and generating second device capability constraints of the second communication device based on the second device capability parameter set; selecting target communication protocols from the subset of common protocols that satisfy both the first and second device capability constraints; initiating a link negotiation request from the first communication device to the second communication device based on the handshake specification of the target communication protocol; and establishing an intermediate communication link between the first and second communication devices for cross-system near-field communication after the second communication device confirms acceptance of the link negotiation request.

[0074] In one embodiment, when the communication link construction module 403 performs the task of determining a subset of common protocols jointly supported by the first communication device and the second communication device based on the first communication feature information and the second communication feature information, it is configured to: extract a set of first near-field communication protocol stacks supported by the first communication device from the first communication feature information; extract a set of second near-field communication protocol stacks supported by the second communication device from the second communication feature information; and perform an intersection operation on the set of first near-field communication protocol stacks and the set of second near-field communication protocol stacks to determine a subset of common protocols jointly supported by the first communication device and the second communication device.

[0075] In one embodiment, when the session identifier generation module 404 generates a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link, it performs the following steps: It acquires multiple available communication paths on the intermediate communication link, performs path decision-making on the multiple available communication paths, and obtains a target communication path; it acquires a first timestamp when the first communication feature information is collected and a second timestamp when the second communication feature information is collected, and determines a common reference timestamp based on the first timestamp and the second timestamp; it generates a random salt value using a preset random number generator, combines the common reference timestamp and the random salt value according to a preset concatenation order, and obtains a fused string; it performs a first round of hash operation on the fused string using a preset first hash algorithm to obtain a first hash value, and performs a second round of hash operation on the fused string using a preset second hash algorithm to obtain a second hash value; it performs a bitwise XOR operation on the high-order part of the first hash value and the low-order part of the second hash value, and performs a bitwise AND operation on the XOR result with a preset fixed mask to obtain a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device.

[0076] In one embodiment, when the session identifier generation module 404 makes path decisions on multiple available communication paths to obtain a target communication path, it is configured to: acquire the near-field file to be transmitted between the first communication device and the second communication device, and calculate the file size of the near-field file; acquire the channel expected bandwidth, channel stability coefficient, and expected transmission power consumption of each available communication path; configure a first weighting coefficient corresponding to the channel expected bandwidth, a second weighting coefficient corresponding to the channel stability coefficient, and a third weighting coefficient corresponding to the expected transmission power consumption based on the file size; perform weighted calculation on the channel expected bandwidth, channel stability coefficient, and expected transmission power consumption based on the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient to obtain the path quality feature value of each available communication path; and select the available communication path with the largest path quality feature value as the target communication path.

[0077] In one embodiment, when the file near-field transfer module 405 constructs a temporary transfer session based on the temporary anonymous session identifier, it is configured to: generate a session creation request based on the temporary anonymous session identifier; send the session creation request to a preset session management server, whereby the session management server verifies the validity of the temporary anonymous session identifier and assigns a unique session identifier to the temporary anonymous session identifier that passes the validity verification; create a temporary session instance on the session management server based on the unique session identifier, and associate and bind the temporary anonymous session identifier with the temporary session instance to obtain the temporary transfer session.

[0078] In detail, each module in the near-field file transfer device 400 based on cross-system communication in this embodiment of the invention uses the same technical means as the near-field file transfer method based on cross-system communication shown in the accompanying drawings, and can produce the same technical effect, which will not be repeated here.

[0079] like Figure 5 The diagram shown is a schematic representation of an electronic device that implements a near-field file transfer method across systems, according to an embodiment of the present invention.

[0080] Electronic device 5 may include processor 50, memory 51, communication bus 52 and communication interface 53, and may also include computer programs stored in memory 51 and run on processor 50, such as near-field file transfer programs based on cross-system communication.

[0081] In some embodiments, the processor 50 may be composed of integrated circuits, such as a single packaged integrated circuit or multiple integrated circuits with the same or different functions, including combinations of one or more central processing units (CPUs), microprocessors, digital processing chips, graphics processors, and various control chips. The memory 51 includes at least one type of readable storage medium, including flash memory, portable hard drives, multimedia cards, card-type memories (e.g., SD or DX memories), magnetic storage, magnetic disks, optical disks, etc. The communication bus 52 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication interface 53 is used for communication between the above-mentioned electronic device and other devices, including network interfaces and user interfaces.

[0082] Figure 5 Only electronic devices with components are shown; it will be understood by those skilled in the art that... Figure 5 The structure shown does not constitute a limitation on the electronic device 5, and may include fewer or more components than shown, or combine certain components, or have different component arrangements.

[0083] It should be understood that the embodiments are for illustrative purposes only and are not limited to this structure in the scope of the patent application.

[0084] Specifically, the processor 50's specific implementation method of the above instructions can be found in the description of the relevant steps in the corresponding embodiments of the accompanying drawings, and will not be repeated here.

[0085] Furthermore, if the modules / units integrated in the electronic device 5 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The computer-readable storage medium can be volatile or non-volatile.

[0086] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and other division methods may be used in actual implementation.

[0087] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional modules.

[0088] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention.

[0089] Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be embraced within the invention. No appended diagram markings in the claims should be construed as limiting the scope of the claims.

[0090] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a system claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A near-field file transfer method based on cross-system communication, characterized in that, The method includes: Collect first communication characteristic information of the first communication device and second communication characteristic information of the second communication device; Based on the first communication feature information and the second communication feature information, determine whether the first communication device and the second communication device belong to the same operating system type; When they do not belong to the same operating system type, an intermediate communication link for cross-system near-field communication is constructed between the first communication device and the second communication device based on the first communication feature information and the second communication feature information. On the intermediate communication link, a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device is generated based on the first communication feature information and the second communication feature information; A temporary transmission session is constructed based on the temporary anonymous session identifier, and the first communication device and the second communication device transfer files within a preset near-field communication range through the temporary transmission session.

2. The near-field file transfer method based on cross-system communication as described in claim 1, characterized in that, The step of determining whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information includes: Extract the first operating system fingerprint feature of the first communication device from the first communication feature information, and extract the second operating system fingerprint feature of the second communication device from the second communication feature information; The similarity between the first operating system fingerprint feature and the second operating system fingerprint feature and each candidate operating system fingerprint template in the preset operating system feature library is calculated respectively, and the first similarity set and the second similarity set are obtained accordingly. The candidate operating system fingerprint template with the highest similarity in the first similarity set is selected as the first operating system fingerprint template, and the first operating system type identifier of the first communication device is obtained based on the first operating system fingerprint template. The candidate operating system fingerprint template with the highest similarity in the second similarity set is selected as the second operating system fingerprint template, and the second operating system type identifier of the second communication device is obtained based on the second operating system fingerprint template; When the first operating system type identifier is the same as the second operating system type identifier, it is determined that the first communication device and the second communication device belong to the same operating system type. When the first operating system type identifier is different from the second operating system type identifier, it is determined that the first communication device and the second communication device do not belong to the same operating system type.

3. The near-field file transfer method based on cross-system communication as described in claim 1, characterized in that, The step of constructing an intermediate communication link between the first communication device and the second communication device for cross-system near-field communication based on the first communication feature information and the second communication feature information includes: Based on the first communication feature information and the second communication feature information, a subset of common protocols jointly supported by the first communication device and the second communication device is determined; Extract a first set of device capability parameters of the first communication device from the first communication feature information, and extract a second set of device capability parameters of the second communication device from the second communication feature information; A first set of device capability parameters is generated for the first communication device, and a second set of device capability parameters is generated for the second communication device. Select target communication protocols from the set of public protocols that all satisfy the first device capability constraint and the second device capability constraint. Based on the handshake specifications of the target communication protocol, the first communication device initiates a link negotiation request to the second communication device; After the second communication device confirms acceptance of the link negotiation request, an intermediate communication link is established between the first communication device and the second communication device for cross-system near-field communication.

4. The near-field file transfer method based on cross-system communication as described in claim 3, characterized in that, The step of determining a subset of common protocols jointly supported by the first communication device and the second communication device based on the first communication feature information and the second communication feature information includes: Extract the first set of near-field communication protocol stacks supported by the first communication device from the first communication feature information; Extract the second near-field communication protocol stack set supported by the second communication device from the second communication feature information; An intersection operation is performed on the first near-field communication protocol stack set and the second near-field communication protocol stack set to determine the common protocol subset jointly supported by the first communication device and the second communication device.

5. The near-field file transfer method based on cross-system communication as described in claim 1, characterized in that, The step of generating a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link includes: Multiple available communication paths on the intermediate communication link are obtained, and path decisions are made on the multiple available communication paths to obtain the target communication path; Obtain the first timestamp when collecting the first communication feature information and the second timestamp when collecting the second communication feature information, and determine a common reference timestamp based on the first timestamp and the second timestamp; A random salt value is generated using a preset random number generator. The public reference timestamp and the random salt value are then combined according to a preset concatenation order to obtain a fused string. A first round of hashing is performed on the fused string using a preset first hash algorithm to obtain a first hash value, and a second round of hashing is performed on the fused string using a preset second hash algorithm to obtain a second hash value; Perform a bitwise XOR operation between the high-order part of the first hash value and the low-order part of the second hash value, and then perform a bitwise AND operation between the XOR operation result and a preset fixed mask to obtain a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device.

6. The near-field file transfer method based on cross-system communication as described in claim 5, characterized in that, The step of making path decisions on multiple available communication paths to obtain a target communication path includes: Obtain the near-field file to be transmitted between the first communication device and the second communication device, and calculate the file size of the near-field file; Obtain the expected channel bandwidth, channel stability coefficient, and expected transmission power consumption for each available communication path; Configure a first weighting coefficient corresponding to the expected channel bandwidth, a second weighting coefficient corresponding to the channel stability coefficient, and a third weighting coefficient corresponding to the expected transmission power consumption configuration based on the file size; The expected bandwidth of the channel, the channel stability coefficient, and the expected transmission power consumption are weighted and calculated based on the first weighting coefficient, the second weighting coefficient, and the third weighting coefficient to obtain the path quality characteristic value of each available communication path; The available communication path with the largest path quality feature value is selected as the target communication path.

7. The near-field file transfer method based on cross-system communication as described in claim 1, characterized in that, The step of constructing a temporary transmission session based on the temporary anonymous session identifier includes: A session creation request is generated based on the temporary anonymous session identifier; The session creation request is sent to a preset session management server, which verifies the validity of the temporary anonymous session identifier and assigns a unique session identifier to the temporary anonymous session identifier that passes the validity verification. A temporary session instance is created on the session management server based on the session unique identifier, and the temporary anonymous session identifier is associated and bound to the temporary session instance to obtain a temporary transmission session.

8. A near-field file transfer device based on cross-system communication, characterized in that, The device includes: A communication feature acquisition module is used to acquire first communication feature information of a first communication device and second communication feature information of a second communication device. The system type identification module is used to determine whether the first communication device and the second communication device belong to the same operating system type based on the first communication feature information and the second communication feature information; The communication link construction module is used to construct an intermediate communication link between the first communication device and the second communication device for cross-system near-field communication when they do not belong to the same operating system type, based on the first communication feature information and the second communication feature information. A session identifier generation module is used to generate a temporary anonymous session identifier for near-field file transfer between the first communication device and the second communication device based on the first communication feature information and the second communication feature information on the intermediate communication link. The file near-field transmission module is used to construct a temporary transmission session based on the temporary anonymous session identifier, and the first communication device and the second communication device realize file transmission within a preset near-field communication range through the temporary transmission session.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the near-field file transfer method based on any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the near-field file transfer method based on any one of claims 1 to 7.

Images