Method and apparatus for generating card, device, and product

Abstract

A method and apparatus for generating a card, a device, and a product. The method comprises: acquiring a generation message used for generating a card; on the basis of the generation message, a target model generating first card data of a predetermined card protocol; converting the first card data into second card data of a custom card protocol; and generating the card on the basis of the second card data. In this way, an ordinary development user can be helped to customize and create a required card interface by means of language descriptions without dragging, thereby further reducing operation procedures, reducing the threshold for developing a card user interface, and improving user experience.

Description

Method, device, apparatus and product for generating card TECHNICAL FIELD

[0001] The present disclosure relates to the field of computer, and more specifically, to a method, device, apparatus and product for generating card. BACKGROUND

[0002] Card UI Design is a user interface design technique widely used in modern websites and mobile applications. It mainly presents content through the component of card, and each card represents a separate information unit, providing users with an intuitive, concise and efficient browsing experience.

[0003] SUMMARY

[0004] In a first aspect of embodiments of the present disclosure, a method for generating a card is provided. The method includes obtaining a generation message for generating the card. The method further includes generating, by a target model, first card data of a predetermined card protocol based on the generation message. The method further includes converting the first card data into second card data of a custom card protocol. In addition, the method further includes generating the card based on the second card data.

[0005] In a second aspect of embodiments of the present disclosure, an apparatus for generating a card is provided. The apparatus includes an obtaining module configured to obtain a generation message for generating the card. The apparatus further includes a first generating module configured to generate, by a target model, first card data of a predetermined card protocol based on the generation message. The apparatus further includes a converting module configured to convert the first card data into second card data of a custom card protocol. In addition, the apparatus further includes a second generating module configured to generate the card based on the second card data.

[0006] In a third aspect of embodiments of the present disclosure, an electronic device is provided. The electronic device includes one or more processors; and a storage device storing one or more programs, when the one or more programs are executed by the one or more processors, cause the one or more processors to implement a method for generating a card. The method includes obtaining a generation message for generating the card. The method further includes generating, by a target model, first card data of a predetermined card protocol based on the generation message. The method further includes converting the first card data into second card data of a custom card protocol. In addition, the method further includes generating the card based on the second card data.

[0007] In a fourth aspect of the embodiments of the present disclosure, a computer program product is provided. The computer program product is tangibly stored on a non-transitory computer readable medium and includes machine executable instructions that, when executed, cause a machine to implement a method for generating a card. The method includes obtaining a generation message for generating a card. The method also includes generating, by a target model, first card data of a predetermined card protocol based on the generation message. The method further includes converting the first card data into second card data of a custom card protocol. In addition, the method also includes generating the card based on the second card data.

[0008] The summary is provided to introduce a selection of concepts, in a simplified form, that are further described below in the detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF DRAWINGS

[0009] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent when described in conjunction with the following detailed description in conjunction with the appended drawings. In the drawings, like or similar reference numerals refer to like or similar elements, in which:

[0010] FIG. 1 illustrates a schematic diagram of an example environment in which multiple embodiments of the present disclosure can be implemented;

[0011] FIG. 2 illustrates a flowchart of a method for generating a card according to some embodiments of the present disclosure;

[0012] FIG. 3 illustrates an example diagram of steps for generating a card according to some embodiments of the present disclosure;

[0013] FIG. 4 illustrates a schematic diagram of a signaling diagram for generating a card according to some embodiments of the present disclosure;

[0014] FIG. 5 illustrates a schematic diagram of an example of generating a card from predetermined card data according to some embodiments of the present disclosure;

[0015] FIG. 6 illustrates an example diagram of an example process of steps for updating a card according to some embodiments of the present disclosure;

[0016] FIG. 7 illustrates a schematic diagram of a signaling diagram for updating a card according to some embodiments of the present disclosure;

[0017] FIG. 8 illustrates a schematic diagram of an interface for updating a card according to some embodiments of the present disclosure;

[0018] FIG. 9 illustrates a block diagram of an apparatus for updating according to some embodiments of the present disclosure; and

[0019] FIG. 10 shows a block diagram of a device that can implement embodiments of the present disclosure. DETAILED DESCRIPTION

[0020] It can be understood that all user-related data involved in the technical solution should be obtained and used after authorization by the user. This means that in the technical solution, if the user's personal information needs to be used, the user's explicit consent and authorization are required before obtaining the data, otherwise the relevant data collection and use will not be carried out. It should also be understood that in the implementation of the technical solution, relevant laws and regulations should be strictly followed in the collection, use and storage of data, and necessary technical and measures should be taken to protect the security of the user's data and ensure the safe use of the data.

[0021] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms, and should not be interpreted as being limited to the embodiments set forth herein, but rather these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes, and are not intended to limit the scope of protection of the present disclosure.

[0022] In the description of embodiments of the present disclosure, the term "comprising" and similar terms are to be understood as open-ended, i.e., "including but not limited to". The term "based on" is to be understood as "based, at least in part, on". The term "one embodiment" or "the embodiment" is to be understood as "at least one embodiment". The terms "first", "second" and the like can refer to different or identical objects, unless explicitly stated otherwise. Other explicit and implicit definitions can also be included below.

[0023] As described above, the card-based user interface design can provide an intuitive browsing experience for users. Although such a card user interface design can be implemented by adopting a specific card protocol, this technical path is not intuitive and user-friendly for non-professionals, as it requires users to have certain technical background or professional knowledge to effectively operate and apply. In the related art, a model can be used to generate a relevant card user interface, reducing the difficulty of user operation. However, this method of accessing the model requires a large amount of model training to enable the model to understand the card protocol required by the card interface, consuming a large amount of computing resources. Moreover, when the card protocol changes, model training often needs to be re-performed, which is costly for developers to maintain. In addition, in the related art, when the user wants to change the card interface, the model returns the full amount of card data, which causes interaction delay and affects user experience.

[0024] To this end, embodiments of the present disclosure provide a scheme for generating a card. With the aid of a target model, card data of a predetermined card protocol is generated according to an obtained generation message about generating a card, and the card data of the predetermined card protocol is then converted into card data of a custom card protocol, and then a card corresponding to the message is generated in real time based on the card data of the custom card protocol.

[0025] In this way, it helps ordinary development users to create a card interface they need through language description without the need for drag-and-drop, further reducing the operation process. Moreover, this method can also avoid adjusting the parameters of the model when the custom card protocol changes, i.e., without the need to retrain the model, thereby reducing the threshold for developing a card user interface and improving the user experience.

[0026] FIG. 1 shows a schematic diagram of an example environment 100 in which embodiments of the present disclosure can be implemented. As shown in FIG. 1, a display interface 110 displays an interface through which a user can implement generation of a custom card.

[0027] In the display interface 110, the user can send a message about the generation of a card requirement through a dialogue box 120 to obtain the relevant card interface in real time. For example, the user can send a text description such as “generate a card to introduce travel in City A, including title, picture, introduction, and detail link” in the dialogue box 120, and when the card generation system in the background receives the message, it can parse the received text description through a target model, so that the target model can generate predetermined card protocol data according to the received text description. In some embodiments, the predetermined card protocol can be a card protocol that can be understood and recognized by the target model, for example, it can be a protocol such as Adaptive Cards, which is written in JSON, so that applications and services can be exchanged publicly. After being passed to a specific application, the JSON file can be converted into a native user interface that can automatically adapt to its environment. It can be understood that in embodiments of the present disclosure, Adaptive Cards will be taken as an example for description, and other card protocols that can be understood and recognized by the target model are also the predetermined card protocols mentioned in the present disclosure. It can be understood that the target model can be a generative model. For example, it can understand and recognize text, and also generate text. In some embodiments, the target model can be a large language model with attention mechanism, and also a generative model with natural language processing technology.

[0028] Continuing to refer to FIG. 1, when the card generation system detects that the predetermined card schema data is generated, the predetermined card schema data can be rendered in the interface of the display interface 110, as shown in the dialog box 140, which displays the card data of the predetermined card schema (i.e., first card data). In some embodiments, the predetermined card schema data can be presented in the form of a JSON file.

[0029] In some embodiments, to enable the user-defined card about traveling in City A to be displayed to the user in real time, the card data of the predetermined card schema (i.e., first card data) generated by the target model can be converted into card data of a custom card schema (i.e., second card data) that can be rendered by a card editor. In some embodiments, the card editor can be a design tool that can simplify the process of creating and managing the card user interface. Inside the card editor, there can be a custom card schema that can be used to represent the card display in the card editor and the runtime scenario. It can be understood that this custom card schema is not understandable by the target model. In some embodiments, the card editor can implement the conversion between the two different card schema data by invoking a schema tool. In the following, the first card data refers to the card data presented in the predetermined card schema, and the second card data refers to the card data presented in the custom card schema.

[0030] Continuing to refer to FIG. 1, the card editor can render the card 130 in real time according to the converted second card data of the custom card schema. It can be seen that the card 130 displays the content consistent with the textual description of “generate a card about traveling in City A, including title, picture, introduction, and detail link”.

[0031] By this method of generating the card data of the predetermined card schema according to the obtained generation message about generating the card by the target model, converting the card data of the predetermined card schema into the card data of the custom card schema, and then generating the card 130 corresponding to the message in real time based on the card data of the custom card schema, the ordinary development user can create the card interface they need from the language description, which further reduces the operation process, reduces the threshold of developing the card user interface, and improves the user experience.

[0032] FIG. 2 illustrates a flowchart of a method 200 for generating a card, according to some embodiments of the present disclosure. The method 200 can be performed by a card generation system. As shown in FIG. 2, at block 202, a generation message for generating a card is obtained. Referring to FIG. 1, in some embodiments, a user can send a generation message for generating a card to the card generation system through a dialog interface, and the generation message can be “Generate a card for introducing travel in City A, including title, picture, introduction, and detail link” as shown in the dialog box 120.

[0033] At block 204, first card data of a predetermined card protocol is generated based on the generation message by a target model. Referring to FIG. 1, after the card generation system receives the card generation message as shown in the dialog box 120 of FIG. 1, the target model of the card generation system can parse the generation message, and thus generate card data of a predetermined card protocol according to the generation message, which can be referred to as first card data of a predetermined card protocol, as shown in the dialog box 140 of FIG. 1. In some embodiments, the predetermined card protocol can be a protocol that can be understood by the target model, for example, can be Adaptive Cards. In some embodiments, the first card data of the predetermined card protocol can be in the form of JSON. It can be understood that the target model can be a generative model. For example, the target model can understand and recognize text, and also can generate text.

[0034] At block 206, the first card data is converted into second card data of a custom card protocol. In order to enable the card defined by the user about travel in City A to be shown to the user in real time, the first data of the predetermined card protocol generated by the target model can be converted into second data of a custom card protocol that can be rendered by a card editor. In some embodiments, the card editor can be a design tool that can simplify the creation and management process of the card user interface. There can be a custom card protocol inside the card editor, which can be used to represent the card display in the card editor and the runtime scenario. It can be understood that this custom card protocol is not easy to be understood by the target model. In some embodiments, the card editor can implement the conversion between the two different card protocol data by calling a protocol tool.

[0035] At block 208, the card is generated based on the second card data. In some embodiments, the card 130 can be rendered in real time according to the converted custom card protocol data. In some embodiments, the process of rendering the card can be implemented by the card editor. Referring to FIG. 1, it can be seen that the content shown in the card 130 is consistent with the textual description of “Generate a card for introducing travel in City A, including title, picture, introduction, and detail link”.

[0036] By means of the target model, the card data of the predetermined card protocol is generated according to the obtained generation message for generating the card, the card data of the predetermined card protocol is converted into the card data of the self-defined card protocol, and then the card corresponding to the message is generated in real time based on the card data of the self-defined card protocol. The method can help ordinary development users to create the card interface they need by language description without drag and drop, further reduces the operation process, reduces the threshold of developing the card user interface, and improves the user experience.

[0037] The steps of generating the card will be described below in combination with FIG. 3 and FIG. 4. FIG. 3 shows an example diagram of the step 300 of generating the card according to some embodiments of the present disclosure. And FIG. 4 shows a schematic diagram of the signaling diagram 400 of generating the card according to some embodiments of the present disclosure. As shown in FIG. 3, at 310, the first card data of the predetermined card protocol is generated by the model. In some embodiments, the first card data of the predetermined card protocol can be generated by the model according to the generation message. Before the first card data of the predetermined card protocol is generated by the model, the generation message sent by the user needs to be obtained.

[0038] In combination with FIG. 4, the user 401 can send a message (generate a card) to the dialogue software development package 403 through 410, so that the dialogue software development package 403 can forward the message to the application development platform 404 through 411. The dialogue software development package 403 can also be called a chat software development kit, that is, the dialogue software development package 403 has the function and interface of building a chat reference. The dialogue software development package 403 can be integrated on the application development platform 404 for interaction of dialogue messages with the user. The display interface 110 shown in FIG. 1 can be the interaction page of the dialogue message. In some embodiments, the application development platform 404 can be a platform for quickly developing intelligent applications, and the user can quickly create various types of chat robots, agents, intelligent applications through the platform, and deploy them in social platforms and instant chat applications. For example, the user can create a chat robot with a card generation function through the application development platform 404.

[0039] When the message (generate card) sent by the user 401 through 410 and 411 is acquired by the application development platform 404, a trigger signal can be sent through 412 to trigger the card generation workflow 405. Then, the card generation system can send a request to the target model 408 through 413 to generate the first card data of the predetermined card protocol, and after the target model 408 generates the first card data, the first card data of the predetermined card protocol can be returned through 414, at which time the card generation workflow 405 has been completed. In some embodiments, the target model can be a large language model with an attention mechanism, and can also be a generative model with natural language processing technology.

[0040] Then, a response about the first card data of the predetermined card protocol that has been generated can be sent to the dialog package 403 through 415, at which time the first card data of the predetermined card protocol that has been generated can be displayed to the user in the dialog box. The content in the dialog box 140 shown in FIG. 1 above is the first card data of the predetermined card protocol generated by the target model 408. In order to render the card to be generated through the card editor 402, the dialog package 403 also needs to send the response to the card editor 402 again through 416. In some embodiments, the predetermined card protocol can be a protocol that can be understood by a large model, for example, it can be an Adaptive Card, which can be presented in the form of a JSON file.

[0041] Returning to FIG. 3, when the target model 408 generates the first card data of the predetermined card protocol, in order to enable the card editor 402 to display the generated card, the first card data of the predetermined card protocol can be converted into the second card data of the custom card protocol at 320. It can be understood that the custom card protocol here is a card protocol customized by the card editor 402, which cannot be understood by the target model 408, but can be used to represent the card display in the card editor and the runtime scenario, so the first card data needs to be converted into the second card data of the custom card protocol that can be recognized by the card editor 402. In combination with FIG. 4, when the card editor 402 receives the response that the first card data of the predetermined card protocol has been generated, the protocol tool 407 can be called through 413 to convert the first card data of the predetermined card protocol into the second card data of the custom card protocol.

[0042] With continued reference to FIG. 4, when the card editor 402 receives the second card data of the custom card protocol through 417, the second card data of the custom card protocol can be stored on the card server 409 through 418, and then the card server 409 can send a response that the data has been stored to the card editor 402 through 419, so as to ensure that the card editor 402 accurately presents the card interface of the user according to the second card data.

[0043] Returning to FIG. 3, at 330, the editor canvas is updated. In conjunction with FIG. 4, when the card editor 402 receives the second card data of the custom card protocol, the card user interface related to the second card data can be rendered and displayed on the canvas of the card editor 402 through 420.

[0044] It can be understood that the generation message sent by the user is not limited to the text type "generate a card for introducing travel in City A, including title, picture, introduction, and detail link" shown in FIG. 1, but can also be card data of a predetermined card protocol that can be recognized by the target model 408, for example, card data under the Adaptive Cards protocol, or card data in JSON form. FIG. 5 shows a schematic diagram of an example 500 of generating a card according to predetermined card data according to some embodiments of the present disclosure. Referring to FIG. 5, the user can send card data of a predetermined card protocol in JSON form through a dialog box 520 of a display interface 510:

[0045] Generate a card, known data is {

[0046] "reviewRating": {

[0047] "ratingValue": 4

[0048] }

[0049] datePublished": "2014-11-28"

[0050] *description": "text description"

[0051] author": "XXX."

[0052] priceRange": "mid-priced"

[0053] "image": "https: / / .......com / bphoto / HoNsxwaCTwKRxvOZs2Shw / is.jpg"

[0054] "name": "YYY."

[0055] }

[0056] Thus, the card 530 corresponding to the above generated message can be generated, and the card data of the predetermined card protocol in the JSON form that the target model 408 can recognize can also be displayed in the dialog box 540. It can be understood that the generated card 530 can not be in the same display interface as the dialog box 540.

[0057] It can be understood that in addition to generating cards, the card generation system can also trigger the workflow 406 for updating the card, so that the generated card page can be updated. The steps for updating the generated card will be described below in conjunction with FIGS. 6-8. FIG. 6 shows an example diagram of an example process of the steps 600 for updating a card according to some embodiments of the present disclosure. FIG. 7 shows a schematic diagram of a signaling diagram 700 for updating a card according to some embodiments of the present disclosure. FIG. 8 shows a schematic diagram of an interface 800 for updating a card according to some embodiments of the present disclosure.

[0058] Referring to FIG. 6, at 610, second card data is obtained. Because the custom card protocol represents the card editor and the card display in the runtime scenario, in order to update the card, the second card data of the custom protocol corresponding to the card needs to be obtained. It can be understood that the workflow for updating the card can be triggered only when the user's message (update card) is received, such as "modify the title of the card page just generated to 'Welcome home!'" in the dialog box 820 shown in the display interface 810 of FIG. 8, and thus the second card data can be obtained.

[0059] In conjunction with FIG. 7, the user 401 can send a message (update card) to the dialog software development kit 403 through 710, so that the dialog software development kit 403 can forward the message to the application development platform 404 through 711, that is, the dialog software development kit 403 has the function of a chat interface. When the message (update card) sent by the user 401 through 710 and 711 is obtained by the application development platform 404, a trigger signal can be sent through 712 to trigger the workflow 406 for updating the card. As described above, the second card data is stored on the card server 409, and then the card generation system needs to send a request for obtaining the second card data to the card server 409 through 713. After that, the card server 409 can return the second card data through 714.

[0060] Returning to Figure 6, after receiving the second card data at 714, it is converted into the first card data at 620. Referring to Figure 7, the protocol tool 407 can be invoked at 715 to convert the second card data back to the first card data. Continuing to refer to Figure 6, at 630, the model generates update protocol data. Referring to Figure 7, after obtaining the first card data, a request can be sent to the target model 408 at 716. This request requests the target model 408 to update the first card data based on the update protocol and the user-sent message (update card) at 717, thus allowing the updated first card data to be obtained at 718. At this point, the card update workflow 406 is complete.

[0061] In some embodiments, the update protocol describes and defines the update mapping relationship between predefined card protocol nodes and custom card protocol nodes, enabling the representation of complex card update logic through a set of indirect and accurate atomic update sequences. For example, in the update protocol, `type` represents the update operation type, which can be `update`, `delete`, or `add`, with `update` being the default. In addition, `path` is defined to represent the path of the attribute to be changed, and rules are defined for `from` followed by the initial value and `to` followed by the target value.

[0062] For example, in the updated protocol, an example of changing the name of a button in a card to "Learn More" could be:

[0063] {"type":"update",

[0064] "path":"$data.btnText",

[0065] "from":"xxx",

[0066] "to": "Learn more"

[0067] }

[0068] For example, a delete button could be:

[0069] {

[0070] "type":"delete",

[0071] "path":"body[number1].property[number2]"

[0072] }

[0073] For example, adding a "Learn More" button could be:

[0074] {

[0075] "type":"add"

[0076] "path":"body[number1].property[number2]",

[0077] "content":{

[0078] "type":"Button",

[0079] "style":"primary",

[0080] "text":"Learn more"

[0081] }

[0082] }

[0083] Here, `content` represents the newly added data content under the corresponding path. In some embodiments, if it is necessary to add an element to an array type field, the path needs to be accurate to the array index position, such as adding an element to the `number2` table at the `number2` index position of the `property` field.

[0084] In some embodiments, changing the button's position, i.e., placing the button at the top, could be an example of:

[0085] {

[0086] "type":"delete",

[0087] "path":"body[number1].property[number2]"

[0088] },{

[0089] "type":"add",

[0090] "path":"body[number3].property[number4]",

[0091] "content":{

[0092] "type":"Button",

[0093] "style":"primary",

[0094] "text":"Buy Now"

[0095] }

[0096] }

[0097] This is a composite update operation, which can first delete the element at body[number1].property[number2], and then add a new button component at body[number3].property[number4].

[0098] In some embodiments, the update logic of the update protocol can be to perform different operations on the update object according to the update object parsed from the update message, including updating, adding or deleting, etc., by judging the type value of the update object. This method of updating the first card data by the target model 408 through the update protocol can reduce the loss of the model updating the first card data.

[0099] Returning to FIG. 6, after the target model 408 updates the first card data through the update protocol, the updated first card data can be obtained at 640. In combination with FIG. 7, in the process of obtaining the updated first card data by the card editor 402, a signal about the updated first card data can also be sent to the dialog package 403 through 719, at which time the user can be shown the updated first card data in the dialog box. The content in the dialog box 840 shown in FIG. 8 is the updated first card data generated by the target model 408 through the update protocol and the protocol tool. Continuing to refer to FIG. 7, in order to render the card to be updated through the card editor 402, the dialog package 403 also needs to send the response to the card editor 402 through 720.

[0100] Returning to FIG. 6, after obtaining the updated first card data, in order to enable the card editor 402 to show the updated card, the updated first card data can be converted into updated second card data at 650. In combination with FIG. 7, when the card editor 402 receives the updated first card data, the protocol tool 407 can be called through 721 to convert the updated first card data into updated second card data.

[0101] Continuing to refer to FIG. 7, when the card editor 402 receives the updated second card data through 722, the updated second card data can be stored on the card server 409 through 723, and then the card server 409 can send a data storage response to the card editor 402 through 724, which can ensure that the card editor 402 accurately presents the user's updated card design.

[0102] Returning to FIG. 6, the editor canvas is updated at 660. In conjunction with FIG. 7, when the card editor 402 receives the updated second card data, the card editor 402 can render a display of the relevant updated card user interface on the canvas of the card editor 402 via 725. The card 830 in the display interface 810 shown in FIG. 8 is the updated card. It can be appreciated that the updated card 830, the dialog box 820, and the dialog box 840 can not be in the same display interface.

[0103] By this method of updating the card by means of the target model, the threshold for developing the card user interface is lowered, and the user’s experience is improved. In addition, this method of updating only the node corresponding to the user’s needs by means of the target model without changing a large amount of card data can also help to avoid a large amount of model training calculation and the corresponding maintenance cost, thereby also improving the user’s development experience.

[0104] FIG. 9 shows a block diagram of an apparatus 900 for generating a card according to some embodiments of the present disclosure. As shown in FIG. 9, the apparatus 900 includes an acquisition module 902 configured to acquire a generation message for generating a card. The apparatus 900 includes a first generation module 904 configured to generate first card data of a predetermined card protocol based on the generation message by a target model. The apparatus 900 includes a conversion module 906 configured to convert the first card data into second card data of a custom card protocol. In addition, the apparatus 900 includes a second generation module 908 configured to generate a card based on the second card data.

[0105] In some embodiments, the first generation module 904 includes a first rendering module configured to render the first card data on a first page in response to detecting generation of the first card data.

[0106] In some embodiments, the conversion module 906 includes a first data conversion module configured to invoke a protocol tool by a card editor to convert the first card data into the second card data, and a first storage module configured to store the second card data on a card server by the card editor.

[0107] In some embodiments, the second generation module 908 includes a first display module configured to display the card on a canvas of the card editor in response to detecting generation of the card.

[0108] In some embodiments, the apparatus 900 further includes a message acquisition module configured to acquire an update message for updating the card, and a first update module configured to update the card based on the update message.

[0109] In some embodiments, the first updating module comprises: a data obtaining module configured to obtain the second card data from the card server in response to detecting the update message; a second updating module configured to update the second card data based on the update message; and a third updating module configured to update the card based on the updated second card data.

[0110] In some embodiments, the second updating module comprises: a second data conversion module configured to invoke the protocol tool to convert the second card data into the first card data; a first data generation module configured to generate the updated first card data based on the update message and the first card data by the target model; and a third data conversion module configured to convert the updated first card data into the updated second card data by the card editor invoking the protocol tool.

[0111] In some embodiments, the third updating module comprises: a fourth updating module configured to update the card by the card editor in response to detecting completion of conversion of the updated second card data; and a second storage module configured to store the updated second card data on the card server by the card editor.

[0112] In some embodiments, the third updating module further comprises: a second rendering module configured to render the updated first card data on the first page in response to detecting generation of the updated first card data; and a second display module configured to display the updated card on the canvas of the card editor.

[0113] In some embodiments, the first data generation module comprises: an initial value obtaining module configured to obtain an initial value of a node corresponding to the update message in the first card data based on the update message; and a target value determining module configured to determine a target value of the node based on the update message; and a second data generation module configured to generate the updated first card data based on the update protocol, the updated first card data comprising at least an update type, an update path, the initial value and the target value of the node.

[0114] FIG. 10 shows a block diagram of a device 1000 that can implement a number of embodiments of the present disclosure. As shown in FIG. 10, the device 1000 includes a central processing unit (CPU) and / or a graphics processing unit (GPU) 1001 that can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 1002 or loaded into a random access memory (RAM) 1003 from a storage unit 1008. Various programs and data required for the operation of the device 1000 can also be stored in the RAM 1003. The CPU / GPU 1001, the ROM 1002, and the RAM 1003 are connected to each other through a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004. Although not shown in FIG. 10, the device 1000 can further include a co-processor.

[0115] A number of components in the device 1000 are connected to the I / O interface 1005, including an input unit 1006, e.g., a keyboard, a mouse, etc., an output unit 1007, e.g., various types of displays, speakers, etc., a storage unit 1008, e.g., a magnetic disk, a magneto-optical disk, etc., and a communication unit 1009, e.g., a network card, a modem, a wireless communication transceiver, etc. The communication unit 1009 allows the device 1000 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0116] The various methods or processes described above can be performed by the CPU / GPU 1001. For example, in some embodiments, the methods can be implemented as a computer software program tangibly embodied in a machine-readable medium, e.g., the storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 1000 via the ROM 1002 and / or the communication unit 1009. When the computer program is loaded into the RAM 1003 and executed by the CPU / GPU 1001, one or more steps or actions of the methods or processes described above can be performed.

[0117] In some embodiments, the methods and processes described above can be implemented as a computer program product. The computer program product can include a computer readable storage medium having computer readable program instructions embodied therewith.

[0118] A computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0119] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0120] Computer readable program instructions for carrying out operations of the present disclosure can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0121] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include a non-transitory computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function / act specified in the flowchart and / or block diagram block or blocks.

[0122] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0123] The computer program product of the second aspect can include a computer readable storage medium. The computer readable storage medium can include instructions. The instructions can include one or both of: instructions for causing a computer to enable a user equipment device to receive a configuration message from a base station, the configuration message comprising an indication of a set of one or more parameters for a first type of hybrid automatic repeat request process, the first type of hybrid automatic repeat request process being associated with a first type of data; and instructions for causing a computer to enable a user equipment device to receive a configuration message from a base station, the configuration message comprising an indication of a set of one or more parameters for a first type of hybrid automatic repeat request process, the first type of hybrid automatic repeat request process being associated with a first type of data.

[0124] Embodiments of the present disclosure have been described above, with the understanding that these embodiments are exemplary only, and are not restrictive, and are not limited to the disclosed embodiments. Many modifications and changes to the described embodiments are possible, without departing from the scope and spirit of the described embodiments. The selection of terms to be used herein is intended to best explain the principles of the embodiments, practical application, or technical improvement over the technology in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

1. A method for generating a card, comprising: obtaining a generation message for generating a card; generating, by a target model, first card data of a predetermined card protocol based on the generation message; converting the first card data into second card data of a custom card protocol; and generating the card based on the second card data.

2. The method of claim 1, wherein generating, by a target model, first card data of a predetermined card protocol based on the generation message comprises: rendering the first card data on a first page in response to detecting generation of the first card data.

3. The method of claim 1, wherein converting the first card data into second card data of a custom card protocol comprises: invoking, by a card editor, the protocol tool to convert the first card data into the second card data; and storing, by the card editor, the second card data on a card server.

4. The method of claim 3, wherein generating the card based on the second card data comprises: displaying the card on a canvas of the card editor in response to detecting generation of the card.

5. The method of claim 1, further comprising: obtaining the update message for updating the card; and updating the card based on the update message.

6. The method of claim 5, wherein updating the card based on the update message comprises: obtaining, from a card server, the second card data in response to detecting the update message; updating the second card data based on the update message; and updating the card based on the updated second card data.

7. The method of claim 6, wherein updating the second card data based on the update message comprises: invoking a protocol tool to convert the second card data into the first card data; generating, by the target model, updated first card data based on the update message and the first card data; and invoking, by a card editor, the protocol tool to convert the updated first card data into updated second card data.

8. The method of claim 7, wherein updating the card based on the updated second card data comprises: updating, by the card editor, the card in response to detecting completion of conversion of the updated second card data; and storing, by the card editor, the updated second card data on the card server.

9. The method of claim 8, further comprising: rendering the updated first card data on a first page in response to detecting generation of the updated first card data; and displaying the updated card on a canvas of the card editor.

10. The method of claim 9, wherein generating, by the target model, updated first card data based on the update message comprises: obtaining, based on the update message, an initial value of a node of the first card data corresponding to the update message; and determining, based on the update message, a target value of the node; and ​ ​ ​ ​ ​ ​ ​ ​ Based on the update protocol, the first card data of the update is generated, and the first card data of the update at least includes an update type of the node, an update path, the initial value, and the target value. 11.An apparatus for generating a card, comprising: an obtaining module configured to obtain a generation message for generating a card; a first generation module configured to generate, by a target model, first card data of a predetermined card protocol based on the generation message; a conversion module configured to convert the first card data into second card data of a self-defined card protocol; and a second generation module configured to generate the card based on the second card data. 12.An electronic device, comprising: a processor; and a memory coupled with the processor, the memory having stored therein instructions that, when executed by the processor, cause the electronic device to perform the method according to any one of claims 1 to 10. 13.A computer program product tangibly stored on a non-transitory computer readable medium and comprising machine executable instructions that, when executed, cause a machine to implement the method according to any one of claims 1 to 10. ​ ​

Images