Methods and equipment for sharing service cards

Abstract

This application provides a method and apparatus for sharing service cards, relating to the field of devices. The method includes: a first device displaying a first service card, the first service card including status information of a target service; the first device establishing a connection with a second device; the first device synchronizing the status information to a second service card in the second device, the second service card corresponding to the same provider application as the first service card, and the second service card being associated with the first service card; when the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information. The technical solution provided by this application implements service cards based on association, allowing the target service executed on the first device to be transferred to the second device for continued execution, fully leveraging the performance of distributed devices and enhancing interactive attributes and engagement.

Description

Technical Field

[0001] This application relates to the field of equipment, and more particularly to a method and equipment for a shared service card. Background Technology

[0002] Service cards are an extended display model for applications. They allow users to set important application information or operations onto cards and embed them into other applications, such as a phone's home screen, achieving direct service access and reducing the number of user experience layers. These cards enable users to access services in one step.

[0003] In existing technologies, devices can create service cards, which will be displayed on the device's desktop or any other interface. However, these service cards are generally only displayed and applied on a single device, which cannot meet the needs of service cards in multi-device scenarios. They cannot leverage the performance of distributed devices and lack interactive attributes and fun. Summary of the Invention

[0004] In view of this, this application provides a method and device for sharing service cards. The method implements service cards based on association, which transfers the target business flow executed on the first device to the second device for continued execution, giving full play to the performance of distributed devices and improving interactive attributes and fun.

[0005] To achieve the above objectives, a first aspect provides a method for sharing a service card, the method comprising: a first device displaying a first service card, the first service card including status information of a target service; the first device establishing a connection with a second device; the first device synchronizing the status information to a second service card in the second device, the second service card corresponding to the same provider application as the first service card, and the first device storing an association relationship between the second service card and the first service card; when the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information.

[0006] In this embodiment, a first device displays a first service card, which includes status information of a target service. A second service card corresponds to the same provider application as the first service card and is associated with it. When a connection is established between the first and second devices, the first device synchronizes its status information to the second service card of the second device, ensuring that both cards contain the same status information. When the first device detects a first control operation on the target service from the first service card, it triggers the second device to respond to the first control operation based on the status information. This achieves the transfer of the target service executed on the first device to the second device for continued execution based on the associated service card, fully leveraging the performance of distributed devices and enhancing interactive attributes and engagement.

[0007] In some implementations, the second service card in the second device may be created based on data provided by the first device, or the second service card in the second device may be generated by the second device in other ways. Regardless of how the second device obtains the second service card, as long as the first device and the second device associate the first service card with the second service card, the method described in any of the first aspects can be performed.

[0008] In some implementations, after the first device synchronizes the status information to the second service card of the second device, the second device can display the second service card, which includes the status information. In some implementations, the second device can display the second service card through the user application of the second service card. In some implementations, the user application of the second service card can be different from the user application of the first service card. The synchronized display of the status information between the first and second service cards provides a more intuitive demonstration to the user that there is a connection and information synchronization between the first service card in the first device and the service card in the second device, facilitating the transfer of services from the first device to the second device.

[0009] In some implementations, the first control operation is used to control the execution process of the target service, or the specific function of the first control operation can correspond to the target service. In some implementations, the first control operation can be used to pause or suspend the execution of the target service, or it can provide other parameters required for executing the target service. For example, if the target service is playing multimedia, the first control operation can include pausing playback, resuming playback, playing the previous multimedia content, playing the next multimedia content, changing the volume, changing the image ratio, liking, or favorited.

[0010] In some embodiments, when the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information. This includes: when the first device detects a first control operation on the target service from the first service card, the first device generates an input event corresponding to the first control operation, the input event including the operation location and operation type of the first control operation on the first service card; the first device sends the input event to the second device, and the input event triggers the second device to respond to the first control operation on the target service. That is, the original user operation is passed to the second device unchanged, and the second device recognizes the user operation and determines how to respond to it, making fuller use of the performance of the second device and making the interaction between the user, the first device, and the second device more engaging.

[0011] In some implementations, the second device can obtain the operation position and operation type of the first control operation in the first service card from the input event, determine the operation position of the second control operation in the second service card based on the size of the second service card and the operation position of the first control operation in the first service card, and generate a virtual second control operation of the operation type at the operation position of the second service card.

[0012] In some embodiments, when the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information, comprising: when the first device detects a first control operation on the target service from the first service card, the first device generates an instruction corresponding to the first control operation; the first device sends the instruction to the second device, and the instruction triggers the second device to respond to the first control operation on the target service. The first device sends the instruction to the second device, and the second device directly executes the instruction, reducing the dependence on the performance of the second device and improving the reliability of executing the target service.

[0013] In some embodiments, the first service card of the first device and the second service card of the second device are both in a connected state. The fact that the first and second service cards are in a connected state indicates that they are establishing a data connection and can interact with each other, such as for information synchronization or business processes. In some embodiments, after the first and second devices are connected, the first device can set the first service card to a connected state, and the second device can set the second service card to a connected state. In some embodiments, when the target business is completed, or when the first and second devices are disconnected, the first device can cancel the connected state of the first service card, and the second device can cancel the connected state of the second service card.

[0014] In some embodiments, the target service includes playing multimedia, the status information includes historical playback information, the first control operation is an operation instructing the playback of multimedia, and the first device triggers the second device to respond to the first control operation on the target service based on the status information, including: the first device triggers the second device to play multimedia based on the historical playback information. That is, multimedia content such as audio, video, and text can be streamed and played continuously on the first device and the second device.

[0015] In some embodiments, before the first device synchronizes the status information to the second service card in the second device, the method further includes: the first device, in response to triggering the operation of sharing the first service card, displays m device identifiers, wherein the m device identifiers correspond to m devices that have card sharing capability and the card sharing capability is enabled, and m is an integer not less than 1; the first device determines the second device from the m device identifiers; the first device sends at least a portion of the data of the first service card to the second device; the at least a portion of the data triggers the second device to create the second service card based on the at least a portion of the data.

[0016] In this embodiment, the first device can display a first service card. In response to triggering the operation of sharing the first service card, it displays m device identifiers, where each of the m device identifiers corresponds to a device with card sharing capability enabled. A second device is then identified from among the m devices, and at least a portion of the data from the first service card is sent to the second device. This allows the second device to create a second service card based on this at least a portion of the data, leveraging the performance of distributed devices and enhancing interactive attributes and engagement.

[0017] In some embodiments, the at least portion of the data includes resource data for rendering the second service card, and the at least portion of the data triggers the second device to display the second service card based on the resource data and automatically install the provider application.

[0018] In some embodiments, the at least partial data includes a second card identifier and identity information of the provider application corresponding to the first service card. The second card identifier is used to identify the second service card shared by the first device to the second device. In some embodiments, the second card identifier may be determined by the first device before sending the at least partial data to the second device. In some embodiments, the first device may store the association between the first card identifier and the second card identifier. The provider application's identity information is used to indicate the provider application of the first service card. In some embodiments, the provider application's identity information may include at least one of the provider application's application name and package name.

[0019] In some implementations, the at least partial data includes at least one of the size of the second service card and the device identifier of the first device.

[0020] In some implementations, at least a portion of the data includes resource data of the first service card.

[0021] In some embodiments, the first device stores the association between the first service card and the second service card, and the method further includes: in response to the completion of the target service or in response to receiving an indication message sent by the second device, the first device deletes the association between the first service card and the second service card.

[0022] In some implementations, the second device can generate new status information for the target service in response to a third control operation on the target service, and synchronize the new status information to the first service card of the first device. In some implementations, the second device can send the new status information to the first device, and the first device replaces the status information in the first service card with the new status information. In some implementations, the third control operation can be the same as or similar to the first control operation. That is, when the target service is transferred from the first device to the second device, the user can also control the target service on the second device, and the first device can synchronously display the status information corresponding to the control, further enhancing the interactive experience.

[0023] A second aspect provides a system comprising a first device and a second device; the first device displays a first service card, the first service card including status information of a target service; the first device establishes a connection with the second device; the first device synchronizes the status information to a second service card in the second device, the second service card corresponding to the same provider application as the first service card, and the first terminal stores the association relationship between the second service card and the first service card; when the first device detects a first control operation on the target service from the first service card, the second device responds to the first control operation on the target service based on the status information.

[0024] The third aspect provides an apparatus for a shared service card, which has the function of implementing the first device behavior in the above aspects and possible implementations of the above aspects. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a transceiver module or unit, a processing module or unit, an acquisition module or unit, etc.

[0025] A fourth aspect provides an apparatus comprising: a memory and one or more processors, the memory for storing a program; and the one or more processors for executing any of the methods described in the first aspect performed by the first apparatus when the program is invoked.

[0026] The fifth aspect provides a chip system including a processor coupled to a memory, the processor executing a program stored in the memory to implement the method performed by the first device according to any of the first aspects above.

[0027] The chip system can be a single chip or a chip module composed of multiple chips.

[0028] A sixth aspect provides a readable storage medium (also referred to as a computer-readable storage medium) having a program stored thereon, which, when executed by a processor, implements the method executed by the first device according to any one of the first aspects described above.

[0029] The seventh aspect provides a program product (also referred to as a computer program product) that, when run on a device, causes the device to perform any of the methods described in the first aspect executed by the first device.

[0030] It is understood that the beneficial effects of the second to seventh aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0031] Figure 1This is a schematic diagram of the structure of a device provided in an embodiment of this application;

[0032] Figure 2 This is a schematic diagram of a display interface provided in an embodiment of this application;

[0033] Figure 3 This is a schematic diagram of another display interface provided in an embodiment of this application;

[0034] Figure 4 This is a schematic diagram of the system architecture provided in an embodiment of this application;

[0035] Figure 5 A flowchart illustrating a method for sharing service cards provided in an embodiment of this application;

[0036] Figure 6 This is a schematic diagram of another display interface provided in an embodiment of this application;

[0037] Figure 7 This is a schematic diagram of another display interface provided in an embodiment of this application;

[0038] Figure 8 A flowchart illustrating a method for processing services provided in an embodiment of this application;

[0039] Figure 9 This is a schematic diagram of another display interface provided in an embodiment of this application;

[0040] Figure 10 A flowchart illustrating another method for sharing service cards provided in this application embodiment;

[0041] Figure 11 This is a schematic diagram illustrating a scenario of a shared service card provided in an embodiment of this application.

[0042] Figure 12 A flowchart illustrating another method for sharing service cards provided in this application embodiment;

[0043] Figure 13 A flowchart illustrating another method for sharing service cards provided in this application embodiment;

[0044] Figure 14 A flowchart illustrating a method for maintaining device information provided in an embodiment of this application;

[0045] Figure 15 A flowchart illustrating another method for sharing service cards provided in this application embodiment;

[0046] Figure 16 A flowchart illustrating another method for sharing service cards provided in this application embodiment;

[0047] Figure 17 A flowchart illustrating another method for processing services provided in this application embodiment;

[0048] Figure 18 A flowchart illustrating another method for processing services provided in an embodiment of this application. Detailed Implementation

[0049] The method for sharing service cards provided in this application can be applied to devices such as mobile phones, tablets, wearable devices, in-vehicle devices, augmented reality / virtual reality devices, laptops, personal computers, netbooks, and personal digital assistants. This application does not impose any restrictions on the specific type of device.

[0050] Figure 1 This is a schematic diagram of the structure of an example device 100 provided in an embodiment of this application. Device 100 may include a processor 110, a memory 120, a communication module 130, and a display screen 140, etc.

[0051] The processor 110 may include one or more processing units, and the memory 120 is used to store program code and data. In this embodiment, the processor 110 can execute instructions stored in the memory 120 for controlling and managing the operation of the device 100.

[0052] The communication module 130 can be used for communication between various internal modules of the device 100, or for communication between the device 100 and other external devices, such as communication with a network or other external devices. For example, the communication module 130 can provide wireless communication solutions applied to the device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), near field communication (NFC), infrared (IR), and other wireless communication technologies. Alternatively, the communication module 130 can provide wireless communication solutions applied to the device 100, including 2G / 3G / 4G / 5G.

[0053] The display screen 140 can display images or videos from the human-computer interaction interface. For example, the display screen can be used to display service cards.

[0054] Optionally, device 100 may also include peripheral devices 150, such as a mouse, keyboard, speaker, microphone, etc.

[0055] It should be understood that, in addition to Figure 1In addition to the various components or modules listed, the embodiments of this application do not specifically limit the structure of device 100. In other embodiments of this application, device 100 may also include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The components illustrated may be implemented in hardware, software, or a combination of software and hardware.

[0056] To facilitate understanding of the technical solutions in the embodiments of this application, the application scenarios of the embodiments of this application will be introduced first below.

[0057] Devices can install a wide variety of applications, each offering different services and providing diverse user experiences. However, as the number of installed applications and the services provided by each application increases, users often need to perform complex operations to open the applications or services. Therefore, to achieve direct service access and reduce experience layers, devices can display service cards (referred to as cards). These service cards can carry relevant application information or operations, allowing users to directly view this information or obtain the corresponding services through these operations.

[0058] Understandably, in practical applications, service cards may include more or fewer software modules or units that can carry application-related information or operations, or service cards may have other names, such as widgets, tiles, business cards, etc.

[0059] The following will use video cards as an example to explain service cards in detail. Please refer to... Figure 2 and Figure 3 This is a schematic diagram of a display interface provided in an embodiment of this application.

[0060] Users can access the following by swiping right on the device's home screen: Figure 2 The negative one screen interface is shown. This negative one screen interface includes a "Huawei Video" card, which includes the video application's identity information, information about the currently playing video, and multiple control buttons. In some embodiments, the identity information may include the video application's icon and name. The information about the currently playing video can be used to indicate information related to the currently playing video; in some embodiments, this video information may include the video window and the video name. The control buttons can be used to control the video playback process; in some embodiments, the control buttons may include a volume bar, a video progress bar, a fast forward button, a rewind button, and a next video button, etc.

[0061] When the device displays as follows Figure 2When the user is on the negative one screen, they can see video cards. The video application's identity information confirms that the content in the video card comes from the video application; the currently playing video information shows the video frame and its name as "Take a Brave Step." Users can also control the video playback using the control buttons, such as adjusting the volume by dragging the volume bar and adjusting the playback progress by dragging the video progress bar.

[0062] In some implementations, a user can click on a blank area of ​​a video card, and the device can respond to the user's click on the blank area by launching the video application and directly jumping to, for example,... Figure 3 The video playback interface shown is illustrated. In some implementations, the video playback interface may include more information than the video card, such as in... Figure 3 The interface can also include video attribute information, video information, and a comment section. Video attribute information may include the number of plays, video type, and video description. Video information may include more playable videos so users can select one to play. The comment section can be used to receive user comments on the currently playing video.

[0063] Alternatively, users can tap the video app icon on the desktop. The device will respond to this tap, launching the video app and displaying its main interface. Users can then navigate through the main interface to find options related to the currently playing video, thus progressing through the hierarchy of options. Figure 3 The video playback interface shown.

[0064] It can be seen that, as Figure 2 The video card shown intuitively and conveniently displays the currently playing video and its related information, along with multiple control buttons for easy user control over the playback process. Users can also directly access the video playback interface through this card, avoiding the tedious process of searching through multiple levels.

[0065] The service cards in the aforementioned devices can bring convenience and fun to users. However, with the continuous development of device technology, multi-device scenarios are becoming increasingly common in users' lives. For example, a user may have multiple devices, or a family group may include devices belonging to multiple users. In multi-device scenarios, devices can interact and collaborate with at least one other device, providing users with a richer experience. Therefore, the current approach where a single device can only create and apply service cards within that device itself cannot meet the needs of service cards in multi-device scenarios. It neither leverages the performance of distributed devices nor provides interactive attributes and fun.

[0066] To address at least some of the aforementioned technical problems, this application provides a method and system for sharing service cards.

[0067] The system architecture involved in this application is described below.

[0068] like Figure 4 As shown, the system includes a source end and a peer end, both of which can be implemented by the aforementioned device 100, and the source end and the peer end can be connected via a network.

[0069] The source is the device that initiates card sharing or business transactions. The source includes the user application, the management framework, and the provider application.

[0070] The user application is a platform for displaying card content. In some implementations, the user application on the source end can be any application on the source end. This application includes a location where service cards can be displayed. For example, locations where service cards can be displayed include the system desktop, lock screen, negative one screen, or any page within the application. In some implementations, the user application includes an entry point for users to operate cards, possessing the permissions and capabilities to operate cards. For example, these capabilities include adding cards, removing cards, sharing cards, refusing to share cards, editing cards, and establishing connections with peers.

[0071] A management framework enables the management of service cards. In some implementations, the management framework can receive instructions from user applications regarding service cards, and perform operations such as adding, deleting, modifying, querying, and sharing service cards based on these instructions. It also coordinates the visual display of the provider application's content on the cards and facilitates user interaction. In some implementations, the management framework may include one or more services, each of which can implement a specific function for managing service cards. For example, the management framework may include a card management service, a package management service, an application management service, a rendering service, and a sharing management service. The card management service manages the persistent proxy services for cards added to the system, including the management and use of card objects and periodic card refreshes. The package management service or application management service manages user applications and provider applications, such as whether the source application includes the provider application for a particular service card. The card rendering service manages card rendering instances, ensuring a one-to-one correspondence between card rendering instances and the cards displayed by the user application. The sharing management service manages shared service cards and the multiple devices associated with them, such as providing information on shareable devices, initiating card sharing, and accepting shared service cards.

[0072] The provider application is used to provide data related to the service card (such as the content display style of the service card) and handle business logic related to the service card. In some implementations, the provider application can be any application in the source end.

[0073] The peer device is a device that accepts and uses service cards shared by the source device, or receives services transferred from the source device. The peer device can be the same as or similar to the source device. For example, both the source and peer devices can be mobile phones; or, the source device can be a mobile phone, and the peer device can be an in-vehicle device, smart screen, TV, computer, etc. The peer device includes user applications, management frameworks, and provider applications.

[0074] In some implementations, the user application on the other end can be any application on the other end, which includes a location where service cards can be displayed.

[0075] In some implementations, the provider application on the other end can be omitted.

[0076] In some implementations, the source and peer devices can communicate via a distributed communication adaptation layer. For example, the distributed communication adaptation layer includes a device profile (DP) manager and a soft bus. The DP is a manager of device hardware capabilities and system software characteristics, used to record device capabilities and status information, such as device type, device name, storage capacity, whether it has a foldable screen, whether it has a screen, resolution, operating system type, operating system version, whether it has card sharing capability, and whether card sharing capability is enabled. The soft bus is a virtual, "invisible" bus that can connect multiple devices on the same local area network.

[0077] In some implementations, the system also includes a server (also known as the cloud) through which the source and peer can communicate.

[0078] As mentioned above Figure 2 Taking the video card shown as an example, the user application is a desktop application, and the provider application is a video application.

[0079] When the source application adds a video card to its negative one screen, the source application can display its desktop. The user swipes right on the desktop to trigger the source application to enter the negative one screen interface, and then clicks the "More" button on that screen. In response to the user's "More" button click, the desktop application displays card addition options, allowing the user to select a video application as the provider. In response to the user's selected provider application, the desktop application sends a request to the management framework to create the video card. The management framework responds to this request by retrieving the video card's resource data from the video application, rendering the resource data to obtain the video card, and sending the video card to the desktop application. The desktop application receives and displays the video card on its negative one screen.

[0080] The resource data for the service card is used to render and display the service card. In some implementations, this resource data includes one or more of the following types of data: text data, configuration data corresponding to the text data, image data, configuration data corresponding to the image data, and structure data. The configuration data corresponding to the text data indicates the attributes of the text data, such as font, font size, color, and background. The configuration data corresponding to the image data indicates the attributes of the image data, such as image name, image size, and image storage location. The structure data is used to organize and manage the above types of resource data. In some implementations, the structure data may include one or more of the following: layout objects, application component objects, helper class objects, mapping relationships, callback functions, and context container objects.

[0081] When a source device shares a video card with another device, the source device can first identify the device to which it is sharing the card and send the video card's card identifier to the other device. The other device then retrieves the corresponding resource data from its video application based on the card identifier and displays the video card on its negative one screen based on that resource data. Alternatively, in some other implementations, when a source device shares a video card with another device, the source device can first identify the device to which it is sharing the card and send the video card's card identifier and corresponding resource data to the other device. The source device can then display the video card on the other device's negative one screen based on the resource data sent by the source device, without requiring a video application.

[0082] Based on the aforementioned system, the shared service card method provided in this application enables the source end to share service cards with the peer end in a multi-device scenario, facilitating service card sharing between the source and peer ends and enabling interaction between two or even multiple ends based on distributed shared service cards. In some embodiments, the service cards shared between the source and peer ends are synchronized; the source end can control the service cards already shared with the peer end; and the peer end can control the service cards of the source end in reverse. Taking service cards used to display multimedia content such as video, music, and text as an example, the source and peer ends can synchronously display the service card, and the multimedia content can be resumed or read between the source end and the device. Taking social applications as another example, the source end can share contact cards with the peer end, that is, share contacts through service cards.

[0083] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0084] Please refer to Figure 5This is a flowchart illustrating a method for sharing service cards provided in an embodiment of this application. The method can be used on a first device to realize the flow and continuity of services between the first and second devices based on service cards associated with each other. In some embodiments, the first device can be referred to as the source end, and the second device as the peer end. It should be noted that this method does not rely on... Figure 5 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0085] S501, the first device displays the first service card, which includes the status information of the target service.

[0086] In some implementations, the target service can be any service performed by the provider application of the first service card, and the status information can be used to indicate the status of the target service. In some implementations, the provider application can be an application that plays multimedia content, the target service can include multimedia playback services, and the status information can include historical playback information, such as playback records, volume, playback progress, etc.

[0087] In some implementations, the first device can display the first service card through a user application within the first device. For example, if the user application is a desktop application, the first device can display the first service card on the desktop application's main screen or the negative one screen.

[0088] S502, the first device establishes a connection with the second device.

[0089] In some implementations, the second device has card-sharing capability and this card-sharing capability is enabled. In some implementations, card-sharing capability may refer to the ability to accept service cards shared by other devices, and / or to share service cards with other devices.

[0090] In some implementations, the second device may be a device that has historically shared service cards with the first device.

[0091] In some implementations, the first device includes m pieces of device information, where m is an integer not less than 1. The first device can determine the second device from the m pieces of device information. The m pieces of device information include the identifiers of the m devices and the sharing information corresponding to the m devices. The sharing information includes: records indicating that the device has card sharing capability and that the sharing capability is enabled, records of the device sharing service cards with the first device, and service cards currently stored in the device that are shared with the first device.

[0092] In some implementations, the first device can query the sharing information of other devices sharing the service card. Alternatively, in other implementations, when the other device joins the network of the first device, it can send the other device's sharing information to the first device.

[0093] S503, the first device synchronizes the status information to the second service card of the second device. The second service card corresponds to the same provider application as the first service card. The first device stores the association relationship between the second service card and the first service card.

[0094] The first device stores the association relationship between the second service card and the first service card; that is, the second service card and the first service card are mutually associated. In some embodiments, the second device also stores the association relationship between the first service card and the second service card. In some embodiments, the first device and the second device can respectively obtain the first card identifier of the first service card and the second card identifier of the second service card, and store the association relationship between the first card identifier and the second card identifier.

[0095] In some implementations, the second service card in the second device may be created based on data provided by the first device, or the second service card in the second device may be generated by the second device in other ways. Regardless of how the second device obtains the second service card, as long as the first service card and the second service card are associated, S503 and subsequent steps can continue.

[0096] In some implementations, after the first device synchronizes the status information to the second service card of the second device, the second device can display the second service card, which includes the status information. In some implementations, the second device can display the second service card through a user application. In some implementations, the user application of the second service card can be different from the user application of the first service card. The synchronous display of the status information between the first and second service cards provides a more intuitive demonstration to the user that there is a connection and information synchronization between the first service card in the first device and the service card in the second device, facilitating the transfer of services from the first device to the second device.

[0097] S504, when the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information.

[0098] Since both the first and second service cards contain the status information of the target service, and the first and second service cards correspond to the same provider application, the second device can also execute the target service in the same or similar way as the first device. Therefore, when the first device and the second device are connected, and the first device detects the first control operation of the target service from the first service card, the first device can trigger the second device to respond to the first control operation of the target service based on the status information in the second service card. This allows the target service executed on the first device to be transferred to the second device for continued execution, fully leveraging the performance of distributed devices and enhancing interactive attributes and fun.

[0099] In some implementations, the first control operation is used to control the execution process of the target service, or the specific function of the first control operation can correspond to the target service. In some implementations, the first control operation can be used to pause or suspend the execution of the target service, or it can provide other parameters required for executing the target service. For example, if the target service is playing multimedia, the first control operation can include pausing playback, resuming playback, playing the previous multimedia content, playing the next multimedia content, changing the volume, changing the image ratio, liking, or favorited.

[0100] In some implementations, after the first device and the second device are connected, the first device can set the first service card to a connection-established state, and the second device can set the second service card to a connection-established state. In some implementations, when the target service is completed, or when the first device and the second device are disconnected, the first device can cancel the connection-established state of the first service card, and the second device can cancel the connection-established state of the second service card. Here, the first service card and the second service card being in a connection-established state indicates that the first service card and the second service card are in the process of establishing a data connection, and data interaction can occur between them, such as information synchronization or service flow.

[0101] In some implementations, the second device can generate new status information for the target service in response to a third control operation on the target service, and synchronize the new status information to the first service card of the first device. In some implementations, the second device can send the new status information to the first device, and the first device replaces the status information in the first service card with the new status information. In some implementations, the third control operation can be the same as or similar to the first control operation. That is, when the target service is transferred from the first device to the second device, the user can also control the target service on the second device, and the first device can synchronously display the status information corresponding to the control, further enhancing the interactive experience.

[0102] In some implementations, the target service includes playing multimedia, the status information includes historical playback information, the first control operation is an operation to instruct the playback of multimedia, and the second device can play multimedia based on the historical playback information. That is, multimedia content such as audio, video, and text can be streamed and played continuously on the first and second devices, and when a user performs a first control operation on the first device, the second device can provide feedback on the first control operation.

[0103] For example, before executing S503, such as Figure 6 As shown in Figure a, the first device (such as a mobile phone) displays a video card (i.e., the first service card) on the negative one screen, and the second device (such as a tablet computer) displays a video card (i.e., the second service card) on the main desktop. The video card is provided by Huawei Video. The content in the video card of the first device is different from the content in the video card of the second device.

[0104] By executing S503, such as Figure 6 As shown in b, the first device synchronizes the historical playback information of the video card to the video card of the second device, so that the content in the video card of the second device is the same as the content in the video card of the second device. The historical playback information includes the last program played by Huawei Video in the first device, the volume, and the playback progress.

[0105] Then continue executing S504, such as Figure 7 As shown in a, when the user clicks the play button in the video card of the first device (i.e., the first control operation), the second device responds to the operation, launches the Huawei Video application on the second device, and continues to play the video based on the historical playback information synchronized on the S503.

[0106] After executing S504 for a period of time, such as Figure 7 As shown in b, when the user clicks the video playback interface of the second device (i.e., the third control operation), the second device responds to the click operation by pausing video playback and sending updated historical playback information to the first device. The first device displays the updated historical playback information in the first service card, where the updated historical playback information includes the new playback progress.

[0107] For users, they can first watch the video on the first device. After the first device is connected to the second device, the historical playback information is transferred to the second device, and then they can continue to watch the video on the second device. At the same time, the user can control the video playback process on the second device through operations on the video card on the first device, such as pausing playback, resuming playback, adjusting volume, and adjusting playback progress.

[0108] In this embodiment, a first device displays a first service card, which includes status information of a target service. A second service card corresponds to the same provider application as the first service card and is associated with it. When a connection is established between the first and second devices, the first device synchronizes its status information to the second service card of the second device, ensuring that both cards contain the same status information. When the first device detects a first control operation on the target service from the first service card, it triggers the second device to respond to the first control operation based on the status information. This achieves the transfer of the target service executed on the first device to the second device for continued execution based on the associated service card, fully leveraging the performance of distributed devices and enhancing interactive attributes and engagement.

[0109] Please refer to Figure 8 This is a flowchart illustrating a method for processing services provided in an embodiment of this application. The method can be described in detail as S504 above. It should be noted that this method is not based on... Figure 8 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0110] S801, when the first device detects a first control operation on the target service from the first service card, the first device generates an input event corresponding to the first control operation. The input event includes the operation location and operation type of the first control operation on the first service card.

[0111] The first control operation can be an operation performed by the user on the first service card. When the first device detects the first control operation, it can generate a corresponding input event so that other modules or other devices in the first device can respond to the first control operation.

[0112] In some implementations, the operation position of the first control operation on the first service card is a relative position with reference to a preset position within the first service card. In some implementations, the preset position can be the upper left corner, lower left corner, upper right corner, lower right corner, or center point of the first service card, and the relative position can be a percentage coordinate of the first control operation within the first service card.

[0113] S802, the first device sends an input event to the second device.

[0114] This input event can trigger the second device to respond with the first control operation for the target service.

[0115] In some implementations, the first device may send input events to the second device via a distributed communication adapter layer or a server.

[0116] S803, the second device generates a virtual second control operation on the second service card based on the input event.

[0117] In some implementations, the second device can obtain the operation position and operation type of the first control operation in the first service card from the input event, determine the operation position of the second control operation in the second service card based on the size of the second service card and the operation position of the first control operation in the first service card, and generate a virtual second control operation of the operation type at the operation position of the second service card.

[0118] For example, such as Figure 9 As shown, when a user clicks the "Next" button on a first service card (i.e., the first control operation) on a first device, the first device sends the operation type and the relative position of the click operation within the first service card to a second device. Based on the operation type and the relative position, the second device generates a virtual click operation (i.e., a virtual second control operation) at the "Next" button on the second service card. For the second device, generating a virtual click operation at the "Next" button on the second service card has the same effect as the user actually clicking the "Next" button on the second service card.

[0119] S804, the second device responds to the second control operation of the target service based on the status information.

[0120] In some implementations, the second device can generate and execute instructions corresponding to the second control operation based on the button or control at the operation position of the second control operation and the operation type of the second control operation. The instructions are used to implement a first control operation on the target service based on status information response.

[0121] For example, such as Figure 9 As shown, the operation position of the second control operation includes a "Next" button, and the operation type is a click operation. Therefore, the second device can generate and execute instructions for playing the next video, thereby responding to the second control operation.

[0122] In some implementations, the second device may respond to the second control operation in the same or similar manner as the first device may respond to the first control operation.

[0123] Alternatively, in other implementations, when the first device detects a first control operation on a target service from the first service card, the first device generates an instruction corresponding to the first control operation. This instruction triggers the second device to respond to the first control operation on the target service. The first device sends this instruction to the second device, which directly executes it, reducing reliance on the performance of the second device and improving the reliability of executing the target service.

[0124] In this embodiment, when the first device detects a first control operation on a target service from the first service card, the first device generates an input event corresponding to the first control operation and sends the input event to the second device. The input event triggers the second device to respond to a second control operation on the target service based on status information. That is, the original user operation is passed directly to the second device, which then identifies the user operation and determines how to respond to it. This makes fuller use of the second device's performance and makes the interaction between the user, the first device, and the second device more engaging.

[0125] Please refer to Figure 10 This is a flowchart illustrating a method for sharing a service card according to an embodiment of this application. This method can be executed after S504 to enable the transfer and continuation of services across more devices. It should be noted that this method does not rely on... Figure 10 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0126] S1001, the first device disconnects from the second device and establishes a connection between the first device and the third device.

[0127] In some implementations, when the first device moves away from the second device and closer to the third device, the first device can switch from being connected to the second device to being connected to the third device. Alternatively, in other implementations, when the distance between the first device and the third device is less than the distance between the first device and the second device, the first device can switch from being connected to the second device to being connected to the third device. Alternatively, in other implementations, when the signal quality of communication between the first device and the third device is better than the signal quality of communication between the first device and the second device, the first device can switch from being connected to the second device to being connected to the third device. Alternatively, in other implementations, the user can actively disconnect the first device from the second device and connect the first device to the third device.

[0128] S1002, the first device synchronizes the new status information to the third service card in the third device. The third service card corresponds to the same provider application as the first service card, and the first device stores the association relationship between the third service card and the first service card.

[0129] The new status information can be generated by the first device or synchronized from the first device by other devices. For example, the new status information can be synchronized from the first device by the second device in the aforementioned S504.

[0130] In some implementations, the method by which the third device obtains the third service card may be the same as or similar to the method by which the second device obtains the second service card.

[0131] In some embodiments, the third device also stores the association relationship between the first service card and the third service card. In some embodiments, the first device and the third device can respectively obtain the first card identifier of the first service card and the third card identifier of the third service card, and store the association relationship between the first card identifier and the third card identifier.

[0132] In some implementations, the way the first device synchronizes new status information to the third service card in the third device can be the same as or similar to the way the first device synchronizes status information to the second service card of the second device in S503.

[0133] S1003, when the first device detects the fourth control operation for the target service from the first service card, the third device responds to the fourth control operation for the target service based on the new status information.

[0134] In some implementations, the way the first device performs S1003 may be the same as or similar to the way the first device performs S504.

[0135] For example, such as Figure 11 As shown, a user is outdoors and watches a video through a video application on a first device he carries with him. The first device displays historical playback information (i.e., status information) in the video card (i.e., the first service card).

[0136] Next, the user moves to the room containing the second device. When the first device establishes a connection with the second device, the first device synchronizes the historical playback information in the video card to the video card (i.e., the second service card) on the second device. When the user clicks on the video card on the first device, the second device launches the video application on the second device and continues playing the video based on the historical playback information.

[0137] Next, the user moves from the room containing the second device to another room containing the third device, switching the connection between the first and second devices to a connection between the first and third devices. Before disconnecting from the second device, the first device retrieves updated historical playback information (i.e., new status information) from the second device and synchronizes this updated historical playback information to the video card (i.e., the third service card) on the third device. The third device can then launch the video application and continue playing the video based on the updated historical playback information.

[0138] As can be seen, during the user's movement from outdoors to the room where the second device is located, and then to another room where the third device is located, although the user's environment changes, the video cards in the first, second, and third devices can be linked and synchronized with historical playback information. Video playback can flow and continue between the first, second, and third devices, allowing the user to watch videos continuously without interruption. Furthermore, the user can control the video playback process on the second and third devices by operating the video cards in the first device.

[0139] In this embodiment, when the first device switches from connecting to the second device to connecting to the third device, the first device can continue to synchronize new status information to the third service card in the third device. When the first device detects a fourth control operation on the target service from the first service card, the third device responds to the fourth control operation on the target service based on the new status information, thereby realizing the flow and continuation of the target service in more devices, further leveraging the performance of distributed devices, and enhancing interactive attributes and fun.

[0140] Please refer to Figure 12 This is a flowchart illustrating a method for sharing a service card according to an embodiment of this application. The method can be as described above. Figure 5 , Figure 8 and Figure 10 This is an alternative implementation of at least some steps of the method shown. It should be noted that this method is not based on... Figure 12 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0141] S1201, the user performs a first control operation on the first service card in the first device.

[0142] S1202, the user application in the first device sends the operation location and operation type of the first control operation to the shared management service in the first device.

[0143] S1203, the shared management service in the first device sends an input event to the shared management service in the second device.

[0144] In some implementations, the input event includes the operation position and operation type of the first control operation.

[0145] S1204, the shared management service in the second device generates a virtual second control operation in the second service card based on the input event.

[0146] S1205, the shared management service in the second device responds to the second control operation and initiates the provider application to execute the target service.

[0147] S1206, The user performs a third control operation on the provider application in the second device.

[0148] S1207, The provider application in the second device instructs the shared management service in the second device to update the service card.

[0149] In some implementations, the provider application in the second device can generate new status information based on a third control operation and send the new status information to the shared management service in the second device, which can then update the second service card with the new status information.

[0150] S1208, The shared management service in the second device synchronizes the card with the card management shared service in the first device.

[0151] In some implementations, the sharing management service in the second device can send new status information to the sharing management service in the first device, and the sharing management service in the first device can update the status information in the first service card to the new status information.

[0152] S1209, if the first device and the second device are disconnected, the user application in the first device can initiate a service card connection request to the sharing management service in the second device through the sharing management service in the first device.

[0153] In some implementations, if the second device already has a second service card, the first device can initiate a service card connection request to the second device. After the second device responds to the request, the first device can set the first service card in the first device to a connection state, and the second device can set the second service card in the second device to a connection state. When both the first and second service cards are in a connection state, the first and second devices can synchronize the first and second service cards, as well as perform service flow and continuity.

[0154] S1210, the shared management service in the first device synchronizes the shared management service card with the shared management service in the second device.

[0155] In some implementations, the shared management service of the first device may send at least some resource data and / or service status information to the shared management service of the second device, thereby making the first service card displayed on the first device the same as the second service card displayed on the second device.

[0156] In some implementations, S1209-S1210 may also be performed before S1201.

[0157] Please refer to Figure 13 This is a flowchart illustrating a method for sharing a service card according to an embodiment of this application. The method can be used to send data from a first device to a second device, causing the second device to generate a service card based on that data. The first device is the source end, and the second device is the peer end. It should be noted that this method does not rely on... Figure 13 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0158] S1301, the first device displays the first service card.

[0159] In some implementations, the user application in the first device can obtain resource data from the provider application in the first device through the management framework in the first device, and display the first service card based on the resource data.

[0160] In some implementations, the first device can edit the displayed first service card.

[0161] For example, if the first service card is a weather card, the first device can determine the location corresponding to the weather when creating the weather card, or it can modify the location corresponding to the weather after displaying the weather card.

[0162] In some implementations, the first device may generate a first card identifier when generating the first service card. The first card identifier is used to identify the first service card in the first device, and the first card identifier may include characters or strings.

[0163] S1302, the first device responds to the operation of triggering the sharing of the first service card by displaying m device identifiers.

[0164] Among them, the m device identifiers correspond to m devices that have card sharing capability and the card sharing capability is enabled, where m is an integer not less than 1.

[0165] In some implementations, users can trigger the sharing of the first service card through preset operations. For example, a first device displays the first service card, and when a user long-presses the first service card, the first device displays an operation window corresponding to the first service card. This operation window includes operation options such as share, remove, and more cards. When the user clicks the share option, the sharing of the first service card is triggered. Alternatively, in other implementations, users can trigger the sharing of the first service card through other means; this application does not limit the triggering method for sharing the service card.

[0166] In some implementations, the devices corresponding to the m device identifiers may be located on the same local area network as the first device. In some implementations, the devices corresponding to the m device identifiers have previously established connections with the first device via near-field communication methods such as Bluetooth and Wi-Fi, or are currently establishing connections with the first device via such near-field communication methods. In some implementations, the user accounts to which the devices corresponding to the m device identifiers belong are the same as or have a binding relationship with the user account to which the first device belongs. For example, the devices corresponding to the m device identifiers and the first device belong to the same user group, or the devices corresponding to the m device identifiers and the first device belong to different users within the same group (e.g., a family group).

[0167] In addition, the first device can also refer to the following Figure 14 The maintenance method shown retrieves and updates m device identifiers.

[0168] S1303, the first device determines the second device from the m device identifiers.

[0169] The first device can identify the second device from m device identifiers.

[0170] In some implementations, when the first device displays m device identifiers, the user can select any one of the m device identifiers as the second device.

[0171] When the second device is identified, the first device is the source end that initiates the sharing of the first service card, and the second device is the peer end to be shared.

[0172] S1304, the first device sends at least part of the data of the first service card to the second device.

[0173] At least a portion of the data is used by the second device to display a second service card associated with the first service card, and / or to automatically download provider applications.

[0174] In some embodiments, the at least partial data includes a second card identifier and identity information of the provider application corresponding to the first service card. The second card identifier is used to identify the second service card shared by the first device to the second device. In some embodiments, the second card identifier may be determined by the first device before sending the at least partial data to the second device. In some embodiments, the first device may store the association between the first card identifier and the second card identifier. The provider application's identity information is used to indicate the provider application of the first service card. In some embodiments, the provider application's identity information may include at least one of the provider application's application name and package name.

[0175] In some implementations, the at least partial data includes at least one of the size of the second service card and the device identifier of the first device.

[0176] In some implementations, at least a portion of the data includes resource data of the first service card.

[0177] S1305, The second device creates a second service card based on at least some of the data.

[0178] In some implementations, the second device can obtain the identity information of the provider application from at least a portion of the received data and detect whether the second device includes the provider application. If so, the second device obtains resource data from the provider application and displays the second service card based on the resource data. In some implementations, if the second device does not include the provider application, the second device can obtain resource data from the first device or the at least a portion of the data and display the second service card based on the resource data; alternatively, the second device can download and install the provider application, then obtain the resource data from the provider application and display the second service card based on the resource data.

[0179] In this embodiment, the first device can display a first service card. In response to triggering the operation of sharing the first service card, it displays m device identifiers, where each of the m device identifiers corresponds to a device with card sharing capability enabled. A second device is then identified from among the m devices, and at least a portion of the data from the first service card is sent to the second device. This allows the second device to create a second service card based on this at least a portion of the data, leveraging the performance of distributed devices and enhancing interactive attributes and engagement.

[0180] Please refer to Figure 14 This is a flowchart illustrating a method for maintaining device information provided in an embodiment of this application. It should be noted that this method is not based on... Figure 14The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0181] S1401, the shared management service in the first device queries the distributed device manager in the first device for online device information.

[0182] The distributed device manager serves as the entry point for distributed services, enabling unified management of both trusted and untrusted devices in the surrounding environment. In some implementations, the distributed device manager can be used to discover surrounding devices, establish trusted relationships by binding with them, query device information, and detect the online and offline status of surrounding devices. Specifically, device online indicates that the device has connected to the network of the first device and is operating normally, while device offline indicates that the device has disconnected from the network of the first device.

[0183] In some implementations, the sharing management service can query the distributed device manager for online device information when the first device enables or disables card sharing capabilities, opens the card sharing capability configuration interface, or restarts the first device. This online device information includes at least one online device.

[0184] S1402, the sharing management service in the first device queries the device description manager in the first device for card sharing capability information of online devices.

[0185] After identifying online devices, the sharing management service can query the device description manager for the card sharing capability information of the online devices. The device's card sharing capability information can indicate whether the device has card sharing capability and whether the card sharing capability is enabled. In some implementations, when a device does not have card sharing capability or its card sharing capability is disabled, the first device cannot obtain the device's card sharing capability information.

[0186] S1403, the first device senses the registration of the shared management service for the device's online / offline status and card sharing capabilities.

[0187] In some implementations, the shared management service can register to sense the online / offline status of currently online devices and their card sharing capabilities.

[0188] In some implementations, the shared management service in the first device can register device online / offline awareness with the distributed device manager in the first device. By registering device online / offline awareness, the shared management service can promptly detect when a device goes online or offline. Taking the second device as an example, if the shared management service has registered the second device online / offline awareness with the distributed device manager, when the second device goes online, the distributed device manager will send an online awareness callback to the shared management service, thereby notifying the shared management service that the second device is online; when the second device goes offline, the distributed device manager will send an offline awareness callback to the shared management service, thereby notifying the shared management service that the second device is offline.

[0189] In some implementations, the sharing management service in the first device can register its card sharing capability information with the device description manager in the first device. By registering its card sharing capability information with a device, the sharing management service can promptly detect changes in the card sharing capability of that device. Taking the second device as an example, if the sharing management service has registered its online / offline status with the device description manager, when the card sharing capability information of the second device changes, the device description manager will send a notification callback to the sharing management service, thus notifying the sharing management service of the change in the card sharing capability information of the second device.

[0190] S1404, The shared management service in the first device updates the information of the shareable devices.

[0191] In some implementations, after the first device updates the shareable device information, the first device can display m device identifiers in the shareable device information. The m devices corresponding to the m device identifiers have card sharing capabilities and the card sharing capabilities are enabled, so that users can share service cards with any of the m devices, or transfer target services to any of the m devices.

[0192] S1405, the distributed device manager in the first device notifies the shared management service in the first device that the second device is online.

[0193] As mentioned above, the distributed device manager registers device online / offline awareness with the shared management service. Therefore, when a second device comes online, the distributed device manager can notify the shared management service that the second device is online.

[0194] For example, when the second device turns on Bluetooth and moves near the first device, the first device can discover that the second device is online via Bluetooth.

[0195] S1406, the sharing management service in the first device queries the device description manager in the first device for card sharing capability information of the second device.

[0196] In some implementations, if the second device has card sharing capability and the card sharing capability is enabled, the first device can obtain the card sharing capability information of the second device; if the second device does not have card sharing capability or the card sharing capability is disabled, the first device cannot obtain the card sharing capability information of the second device.

[0197] S1407, the shared management service in the first device registers its awareness of the card capability information of the second device with the device description manager in the first device.

[0198] By registering and sensing information about the card-sharing capabilities of the second device, changes in the card-sharing capabilities of the second device can be detected in a timely manner.

[0199] S1408, The shared management service in the first device updates the information of the shareable devices.

[0200] In some implementations, when it is determined that the second device is online, has card sharing capability, and the card sharing capability is enabled, the sharing management service in the first device can add the second device to the device information of the shareable card.

[0201] In some implementations, after the first device displays the shareable device information obtained through S1404, if it detects that the second device is online, has card sharing capability, and the card sharing capability is enabled, it updates the shareable device information again through S1408.

[0202] S1409, the distributed device manager in the first device notifies the shared management service in the first device that the second device is offline.

[0203] When the second device goes offline, the distributed device manager can notify the shared management service that the second device is offline.

[0204] For example, if the second device turns off Bluetooth or moves away from the first device, the first device may be unable to discover the second device via Bluetooth, thus determining that the second device is offline.

[0205] S1410, The shared management service in the first device updates the information of the shareable devices.

[0206] In some implementations, when it is determined that the second device is offline, the shared management service in the first device can remove the second device from the current list of shareable devices.

[0207] In some implementations, after the first device displays the shareable device information obtained through S1404 or S1408, it updates the shareable device information again through S1410 if it detects that the second device is offline.

[0208] S1411, When the card sharing capability configuration of the second device is changed, the sharing management service in the second device notifies the device description manager in the second device of the card sharing capability configuration change event, which includes the changed card sharing capability information.

[0209] In some implementations, when the device description manager in the second device obtains the modified card sharing capability information, the device description manager in the second device can notify the device description managers of other devices of the modified card sharing capability information through a distributed communication adaptation layer.

[0210] S1412, the device description manager in the first device notifies the sharing management service in the first device of the change in the card sharing capability information of the second device.

[0211] As mentioned above, the sharing management service in the first device registers the awareness of the card sharing capability information of the second device with the device description manager in the first device. Therefore, when the card sharing capability of the second device changes, the device description manager can notify the sharing management service of the change in the card sharing capability information of the second device.

[0212] S1413, The shared management service in the first device updates the information of the shareable devices.

[0213] In some implementations, if the card sharing capability of the second device changes from an enabled state to a disabled state, the sharing management service in the first device removes the second device from the shareable device information; if the card sharing capability of the second device changes from a disabled state to an enabled state, the sharing management service in the first device adds the second device to the shareable device information.

[0214] In some implementations, after the first device displays the device information obtained through S1404 or S1408, if the second device enables or disables the card sharing capability, the shareable device information is updated again by executing S1413.

[0215] In this embodiment, the first device can actively query other online devices that have card sharing capabilities and whose sharing capabilities are enabled, display the information of the shareable devices, and update the shareable device information when the other device comes online or when the card sharing capability information changes, thereby improving the accuracy of the shareable device information and thus improving the reliability of sharing service cards with other devices.

[0216] Please refer to Figure 15 This is a flowchart illustrating another method for sharing service cards provided in an embodiment of this application. The method can be implemented as described above. Figure 13 The process is executed before step S1305 in the method shown. It should be noted that this method does not preclude... Figure 15 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0217] S1501, the user application in the first device initiates a sharing of the first service card to the card sharing service in the second device.

[0218] In some implementations, the user application in the first device can send at least a portion of the data of the first service card to the card-sharing service in the second device, thereby initiating the sharing of the first service card with the card-sharing service of the second device. In some implementations, the at least a portion of the data may include a second card identifier, the identity information of the provider application, the size of the second service card, and the device identifier of the first device.

[0219] S1502, the shared management service in the second device requests the user application in the second device to add a second service card.

[0220] In some implementations, the sharing management service in the second device can send at least a portion of the data received from the first device to a user application in the second device. The user application can then display this at least a portion of the data to the user of the second device so that the user can decide whether to accept or reject the sharing from the first device.

[0221] After the shared management service in the second device requests the user application in the second device to add a second service card by executing S1502, the second device may execute S1503, S1505 or S1507 depending on the user's choice.

[0222] S1503, if the user of the second device chooses to fully trust the first device, the user application in the second device can notify the sharing management service in the second device to add the first device to the trust list.

[0223] In some implementations, the trust list may include at least one device. After the first device is added to the trust list, when the card sharing service in the second device receives a service card sharing request initiated by the first device again, it does not need to ask the user whether to trust the first device again, but can directly execute S1504.

[0224] S1504, the shared management service in the second device requests the user application in the second device to create a second service card.

[0225] In some implementations, after the sharing management service in the second device requests the creation of a second service card from the user application in the second device, the user application can execute the aforementioned S1305 to display the second service card.

[0226] S1505, if the user of the second device chooses to trust the first device only once, the user application in the second device shall notify the shared management service in the second device to trust the first device only once.

[0227] When the user of the second device selects "only one device at a time," the second device only agrees to receive the content shared by the first device in this instance.

[0228] S1506, The shared management service in the second device requests the user application in the second device to create a second service card.

[0229] The way the second device executes S1506 can be the same as or similar to the way the second device executes S1504.

[0230] S1507, if the user of the second device chooses to reject the first device once, the user application in the second device shall notify the sharing management service in the second device to reject the content shared by the first device this time.

[0231] When the user of the second device chooses to reject the first device once, the second device rejects the content shared by the first device this time, and the service card sharing process ends.

[0232] In some implementations, when the user of the second device chooses to reject the first device once, the following steps S1508 and S1509 can still be executed.

[0233] S1508, The shared management service in the second device records the number of times the first device was rejected.

[0234] In some implementations, the number of times the first device is rejected can be the number of consecutive rejections of the first device within the most recent preset time period, or it can be the cumulative number of rejections of the first device in history.

[0235] S1509, if the number of times the first device is rejected exceeds the preset number, the sharing management service in the second device will ask the user application whether to blacklist the first device.

[0236] In some implementations, when the number of times the first device is rejected exceeds a preset number, the sharing management service in the second device may request the user application to show the user the option to blacklist the first device.

[0237] For example, the preset number of attempts is 3. If the first device is rejected twice in a row when sharing the first service card with the second device, the second device can display the option to block the first device when the first device tries to share the first service card with the second device for the third time.

[0238] S1510, if the user of the second device chooses to blacklist the first device, the sharing management service of the second device can add the first device to the blacklist.

[0239] In some implementations, the blacklist may include at least one device. After a first device is added to the blacklist, when the card sharing service in the second device receives a service card sharing request initiated by the first device again, it does not need to ask the user whether they trust the first device. Instead, it can directly reject the content shared by the first device, so that the user is no longer aware of the content shared by the first device until the user removes the first device from the blacklist.

[0240] Please refer to Figure 16 This is a flowchart illustrating another method for sharing service cards provided in an embodiment of this application. The method can be described in detail in the aforementioned S1305. It should be noted that this method is not based on... Figure 16 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0241] S1601, the sharing management service in the second device queries the package management service in the second device to see if the provider application exists in the second device. If the provider application exists in the second device, proceed to S1602; if the provider application does not exist in the second device, proceed to S1605.

[0242] In some implementations, the sharing management service in the second device can send the identity information of the provider application to the package management service. Based on the identity information of the provider application, the package management service queries whether there is a provider application in the second device that corresponds to the identity information of the provider application. The card management service in the second device returns the query result, which can indicate whether there is a provider application in the second device.

[0243] S1602, the shared management service in the second device obtains resource data from the provider application in the second device and creates a second service card based on the resource data.

[0244] When a provider application exists in the second device, the sharing management service in the second device can obtain the resource data required to create the second service card from the provider application in the second device and create the second service card with the resource data, without having to rely on the first device to provide the resource data. This reduces the interaction process between the first device and the second device and improves the efficiency of sharing cards.

[0245] In some implementations, when creating a second service card, the sharing management service in the second device can determine the size of the second service card based on display attribute information such as the screen size and shape of the second device. In some implementations, the scaling ratio between the second service card and the first service card can be expressed as... Among them, w sink h sink This indicates the width and height of the second service card, w src h src This indicates the width and height of the first service card. In some embodiments, if the screen of the second device is an irregularly shaped screen, the width and height of the second device can be the width and height of the rectangular area included in the irregularly shaped screen.

[0246] In some implementations, the first device can configure the second service card as a temporary card or a non-temporary card. If the second service card is a temporary card, the second device will also delete the second service card when the first device disconnects from the second device or when the first device deletes the first service card. If the second service card is a non-temporary card, the second device can retain the second service card when the first device disconnects from the second device or when the first device deletes the first service card.

[0247] In some implementations, the first device can be configured to configure the first service card in the first device as a temporary card or a non-temporary card. If the first service card is a temporary card, the first device deletes the first service card when the second device successfully creates and displays the second service card (i.e., the first device successfully shares the service card with the second device). If the first service card is a non-temporary card, the first device can retain the first service card when the second device successfully creates and displays the second service card.

[0248] S1603, the shared management service in the second device notifies the shared management service in the first device of the stored pairing data.

[0249] When the second device successfully creates and displays the second service card, the shared management service in the second device notifies the shared management service in the first device to store the pairing data, which facilitates the subsequent management and control of the first service card in the first device and the second service card in the second device, such as synchronizing the first service card and the second service card, and performing business flow based on the first service card and the second service card.

[0250] In some implementations, the pairing relationship may include an association between a first service card and a second service card.

[0251] S1604, The shared management service in the first device stores pairing data.

[0252] In some implementations, the pairing data may include the association between the card identifier of the first service card and the card identifier of the second service card, and / or the association between the device identifier of the first device and the device identifier of the second device.

[0253] S1605, the sharing management service in the second device notifies the sharing management service in the first device that the second device does not meet the card creation conditions.

[0254] In the absence of a provider application in the second device, the sharing management service in the second device notifies the sharing management service in the first device that the second device does not meet the card creation conditions, thereby obtaining the resource data provided by the first device. This enables the first device to successfully share service cards with the second device even when no provider application is available, improving the reliability of the shared service cards.

[0255] Alternatively, in other implementations, the sharing management service in the first device can determine that card sharing has failed upon receiving a notification that the second device does not meet the card creation conditions, and thus not continue to execute subsequent steps.

[0256] S1606, the shared management service in the first device obtains the resource data of the first service card and packages it.

[0257] In some implementations, the shared management service in the first device can obtain resource data corresponding to the first service card from the application providing the first device.

[0258] S1607, the shared management service in the first device sends packaged data to the shared management service in the second device.

[0259] In some implementations, the shared management service in the first device can send packaged data to the shared management service in the second device based on the distributed communication adaptation layer.

[0260] S1608, the shared management service in the second device parses and packages data.

[0261] The shared management service in the second device parses and packages the data to obtain resource data.

[0262] In some implementations, the first device may not package the resource data, and the corresponding second device can directly receive the resource data sent by the first device without parsing the packaged data. That is, S1608 can be omitted.

[0263] S1609, the shared management service in the second device creates a second service card based on the parsed resource data.

[0264] In some implementations, the way the second device performs S1609 to create a second service card based on resource data can be the same as or similar to the way it performs S1602 to create a second service card based on resource data.

[0265] In some implementations, if the second device, after receiving resource data sent by the first device and creating a second service card based on that resource data, subsequently installs a provider application, the package management service in the second device can notify the sharing management service in the second device that the provider application is already installed. Upon receiving this notification, the sharing management service in the second device can retrieve the resource data from the provider application in the second device and recreate the second service card based on that resource data. In some implementations, the sharing management service in the second device can, after reconstructing the second service card based on the resource data provided by the provider application in the second device, notify the sharing management service in the first device that a provider application exists in the second device and that the first device does not need to provide resource data.

[0266] S1610, the shared management service in the second device notifies the shared management service in the first device of the stored pairing data.

[0267] S1611, The shared management service in the first device stores pairing data.

[0268] In some implementations, the second device may perform S1610 in the same or similar manner as it performs S1603, and the first device may perform S1611 in the same or similar manner as it performs S1604.

[0269] In this embodiment, when the second device accepts a shared service card, it can obtain resource data from the provider application on the second device if the second device has a provider application, and then display the second service card based on this resource data. This allows the shared service card to be completed with less data required from the first device, improving the efficiency of the shared service card. Alternatively, if the second device does not have a provider application, it can first obtain the resource data from the first device and then display the second service card based on this resource data, ensuring the shared service card is implemented. Furthermore, if the provider application is subsequently installed on the second device, the resource data can be obtained again from the provider application on the second device, and the second service card can be re-implemented based on this resource data, further reducing the shared service card's dependence on the first device.

[0270] Please refer to Figure 17 This is a flowchart illustrating another method for processing services provided in an embodiment of this application. This method allows the second device to process services flowing from the first device when a second service card in the second device is associated with a first service card in the first device; and when the association between the second service card in the second device and the first service card in the first device is canceled, the second device can independently process other services based on the second service card. It should be noted that this method does not rely on... Figure 17 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0271] S1701, the first device establishes an association between the first service card and the second service card in the second device.

[0272] In some implementations, the second service card in the second device may be created based on data provided by the first device. For example, the second device can utilize the aforementioned... Figure 13 The method shown generates the second service card. Alternatively, in other embodiments, the second service card in the second device may be obtained by the second device through other means. Regardless of how the second service card in the second device is obtained, as long as the first service card and the second service card correspond to the same provider application, the first device can establish an association between the first service card and the second service card in the second device, thereby enabling at least a portion of the data of the first service card and the second service card to be shared.

[0273] In some implementations, after executing S1701 to establish the association between the first service card and the second service card, the first device and the second device can perform the aforementioned... Figure 5The method shown transfers the target service flow from the first device to the second device for continued execution.

[0274] S1702, the second device, in response to detecting a fifth control operation from the second service card, displays the first interface.

[0275] The fifth control operation can be any type of operation. For example, the fifth control operation can be a click operation.

[0276] In some implementations, the first interface can be determined based on a second service card and a fifth control operation. For example, if the second service card is a contact card and the fifth control operation is clicking on that contact card, then the first interface is an interface for adding contacts.

[0277] S1703, the first device deletes the association between the first service card and the second service card.

[0278] In some implementations, after the target service is completed, the first device may actively delete the association between the first service card and the second service card in response to the completion of the target service, or the second device may send an instruction message to the first device, and the first device may delete the association between the first service card and the second service card upon receiving the instruction message.

[0279] In some implementations, if the second device also stores the association between the first service card and the second service card, then when the first device deletes the association between the first service card and the second service card, the second device can also delete the association between the first service card and the second service card.

[0280] S1704, the second device, in response to detecting a fifth control operation from the second service card, displays a second interface, which is different from the first interface.

[0281] Even after the association between the first and second service cards has been severed, the second device can still display the second interface if it detects the same fifth control operation. In other words, depending on whether the association between the first and second service cards exists or not, the second device can respond to the same control operation detected from the second service card in different ways, such as displaying different interfaces or handling different business processes. This further leverages the performance of distributed devices and enhances interactivity and engagement.

[0282] For example, if the second service card is a contact card and the fifth air operation is to click on the contact card, then the second interface is an interface for calling the contact.

[0283] In this embodiment, when there is an association between the first service card and the second service card, the second device displays the first interface in response to detecting the fifth control operation from the second service card. In the case where there is no association between the first service card and the second service card, the second device displays the second interface in response to the same fifth control operation, thereby further leveraging the performance of the distributed device and improving the interactive attributes and fun.

[0284] Please refer to Figure 18 Taking the contact card as an example, for Figure 17 The method shown will be explained in more detail. It should be noted that this method is not based on... Figure 18 The specific order described below is a limitation. It should be understood that in some embodiments, the order of some steps in the method can be interchanged according to actual needs, or some steps can be omitted or deleted. The method includes the following steps:

[0285] S1801, the user clicks on the contact card in the first device, triggering the sharing of the contact card to the second device.

[0286] The contact card in the first device is the first service card.

[0287] In some implementations, the first device can generate a corresponding contact card from the contact information to be shared, and the contact card includes the contact information.

[0288] Understandably, in practical applications, users can also trigger the sharing of contact cards to a second device through other means.

[0289] S1802, the first device initiates a sharing request to the second device.

[0290] In some implementations, the first device may be based on the foregoing Figure 13 The method shown initiates sharing to the second device.

[0291] S1803, Second device startup provider application.

[0292] In some implementations, the second device can launch a provider application (such as a contacts application) through a shared management service, obtain the resource data required to display the contact card from the provider application, and create the contact card based on the resource data.

[0293] S1804, the second device displays the contact card.

[0294] The contact card displayed on the second device is the second service card, and the contact card includes contact information shared by the first device.

[0295] In some implementations, the second device may display the second service card on any interface of the user's application.

[0296] In some implementations, after the second device displays a contact card, the first device can store the association between the contact card in the first device and the contact card in the second device. In some implementations, if this association exists, when the first device updates the contact card in the first device, the second device can synchronously update the contact card in the second device.

[0297] S1805, when the user clicks on the contact card displayed on the second device, the user application in the second device passes the input event to the sharing management service in the second device.

[0298] The input event is used to instruct the user to click on a contact card.

[0299] S1806, The second device launches the provider application and displays the interface for adding contacts.

[0300] The interface for adding contacts is the first interface.

[0301] In some implementations, the interface for adding a contact includes contact information from a contact card.

[0302] In some implementations, the second device can modify information in the interface for adding contacts, such as changing the name or profile picture.

[0303] S1807, the second device updates the target interface corresponding to the contact card after the user adds a contact.

[0304] In some implementations, when a user successfully adds the contact indicated by the contact card on the second add contact interface, the provider application can instruct the sharing management service to update the target interface corresponding to the contact card to the interface for calling the contact, which is the second interface. In some implementations, the interface for calling the contact can be used to initiate a call or chat with the contact.

[0305] S1808, the second device notifies the first device to cancel the association of the contact card.

[0306] In some implementations, the provider application in the second device can notify the sharing management service in the second device to cancel the association of the contact card. The sharing management service in the second device then notifies the sharing management service in the first device to cancel the association of the contact card. After receiving the notification, the sharing management service in the first device deletes the association between the contact card in the first device and the contact card in the second device, making the contact card in the first device and the contact card in the second device independent service cards.

[0307] In some implementations, the second device may first execute S1808 to notify the first device to cancel the association of the contact card, and then execute S1807 to update the target interface corresponding to the contact card.

[0308] S1809, when the user clicks the contact card displayed on the second device again, the user application on the second device passes the input event to the sharing management service on the second device.

[0309] The way the second device executes S1809 can be the same as the way it executes S1805.

[0310] S1810, the second device launches the provider application and displays the interface for calling the contact.

[0311] pass Figure 18 The method shown enables contact sharing among multiple devices and users based on card sharing capabilities. The first device can generate contact cards from contact information in its social application and then share these contact cards with the social application in the second device. Users on the second device can add new contacts in the social application based on the shared contact cards, and can also view other information related to the contacts through the contact cards, thus improving the convenience and fun of social interaction.

[0312] Based on the same inventive concept, as an implementation of the above method, this application provides a device for sharing service cards. This device embodiment corresponds to the aforementioned method embodiment. For ease of reading, this device embodiment will not repeat the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can implement all the contents of the aforementioned method embodiment.

[0313] In one possible implementation, the device may correspond to the first device, second device, or third device in the above method embodiments. For example, it may be the first device, second device, or third device, or a chip configured in the first device, second device, or third device. The device is used to perform the various steps or processes corresponding to the first device, second device, or third device in the above method.

[0314] Based on the same inventive concept, this application also provides an apparatus. The apparatus includes: a memory and one or more processors, the memory for storing a program; and the one or more processors for executing the methods performed by the first, second, or third apparatus in the above method embodiments when the program is invoked.

[0315] The device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0316] Based on the same inventive concept, this application also provides a chip system. The chip system includes one or more processors coupled to a memory, which execute programs stored in the memory to implement the methods performed by the first device, second device, or third device in the above method embodiments.

[0317] The chip system can be a single chip or a chip module composed of multiple chips.

[0318] This application also provides a readable storage medium (also known as a computer-readable storage medium) storing a program thereon, which, when executed by a processor, implements the method performed by the first device, the second device, or the third device in the above method embodiments.

[0319] This application also provides a program product (also known as a computer program product) that, when run on a device, enables the device to execute the method performed by the first device, the second device, or the third device in the above method embodiments.

[0320] Based on the same inventive concept, as an implementation of the above method, embodiments of this application provide a system including a first device and a second device from the above method embodiments. In some embodiments, the system further includes a third device from the above method embodiments. The first device can execute the method executed by the first device in the above method embodiments, the second device can execute the method executed by the second device in the above method embodiments, and the third device can execute the method executed by the third device in the above method embodiments.

[0321] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of some embodiments.

[0322] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of software and hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0323] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0324] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0325] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0326] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0327] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for sharing service cards, characterized in that, The method includes: The first device displays a first service card, which includes the status information of the target service; The first device establishes a connection with the second device; The first device synchronizes the status information to the second service card in the second device. The second service card corresponds to the same provider application as the first service card, and the first device stores the association relationship between the second service card and the first service card. When the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information.

2. The method according to claim 1, characterized in that, When the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information, including: When the first device detects a first control operation on the target service from the first service card, the first device generates an input event corresponding to the first control operation. The input event includes the operation location and operation type of the first control operation on the first service card. The first device sends the input event to the second device, and the input event triggers the second device to respond to the first control operation on the target service.

3. The method according to claim 1, characterized in that, When the first device detects a first control operation on the target service from the first service card, the first device triggers the second device to respond to the first control operation on the target service based on the status information, including: When the first device detects a first control operation on the target service from the first service card, the first device generates an instruction corresponding to the first control operation. The first device sends the instruction to the second device, and the instruction triggers the second device to respond to the first control operation on the target service.

4. The method according to any one of claims 1-3, characterized in that, The first service card of the first device is in a connection state, and the second service card of the second device is in a connection state.

5. The method according to any one of claims 1-4, characterized in that, The target service includes playing multimedia, the status information includes historical playback information, the first control operation is an operation to instruct the playback of multimedia, and the first device triggers the second device to respond to the first control operation on the target service based on the status information, including: The first device triggers the second device to play multimedia based on the historical playback information.

6. The method according to any one of claims 1-5, characterized in that, Before the first device synchronizes the status information to the second service card in the second device, the method further includes: In response to triggering the operation of sharing the first service card, the first device displays m device identifiers, wherein the m devices corresponding to the m device identifiers have card sharing capability and the card sharing capability is enabled, and m is an integer not less than 1; The first device identifies the second device from the m device identifiers; The first device sends at least a portion of the data from the first service card to the second device; The at least part of the data triggers the second device to create the second service card based on the at least part of the data.

7. The method according to claim 6, characterized in that, The at least part of the data includes resource data for rendering the second service card, and the at least part of the data triggers the second device to display the second service card based on the resource data and automatically install the provider application.

8. The method according to any one of claims 1-7, characterized in that, The first device stores the association relationship between the first service card and the second service card, and the method further includes: In response to the completion of the target service or in response to receiving an instruction from the second device, the first device deletes the association between the first service card and the second service card.

9. A device, characterized in that, include: A memory and one or more processors, the memory being used to store a program; the one or more processors being used to execute the method as described in any one of claims 1-8 when the program is invoked.

10. A readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-8.

11. A program product, characterized in that, When the program product is run on the device, the device performs the method as described in any one of claims 1-8.

Images