Multi-schema version support in data synchronization

Abstract

A computer-implemented method for managing application data consistency between multiple computing devices within a communication network includes retrieving, by a first device, application data from a second device. The application data includes an app ID and a first application version number of an app residing on the second device. A first database table is updated using an object type associated with the app ID and the first application version number. The object type identifies a database table schema for a data object used by the app and a plurality of data fields of the data object. Data stored in one or more of the plurality of data fields is synchronized with the third device based on the second application version number of the app residing on the third device and the first database table.

Description

Technical Field

[0001] The present disclosure relates to schema version support in conjunction with data synchronization technology in communication networks, such as Mobile Backend as a Service (or MBaaS) architectures, including technologies for application data consistency management across multiple devices and technologies for multiple schema version support in data synchronization. Background Art

[0002] Computing devices (e.g., mobile computing devices) are generating more data and consuming more power to process the increased data volumes. Furthermore, as the number of portable and mobile devices increases, data collected from such devices may need to be accessed and synchronized at multiple network locations within a network architecture for different purposes, including analysis, artificial intelligence (AI) processing, business intelligence processing, or other analysis or data processing functions.

[0003] The network architecture may include a Mobile-Backend-as-a-Service (MBaaS) architecture, which can serve as an integrated distributed data management system that simplifies user application ("app") development and data management on devices and within the network. In some aspects, the MBaaS architecture can be used to provide web app and mobile app developers with a way to connect their applications to backend data storage and application programming interfaces (APIs), including services provided by a hosting provider. In this regard, the MBaaS architecture assists app developers in setting up and maintaining backend data services.

[0004] Each app executed on a computing device within a network architecture (e.g., within an MBaaS architecture) may be updated multiple times during its lifecycle to fix defects (or "bugs") or add new features. However, a user may own or use multiple computing devices, and the user may not update all of them to the same app version at the same time. In this regard, the user may continue to use different versions of the app on different devices, which may cause data change and data synchronization issues between the user's computing devices. Summary of the Invention

[0005] Examples are now described to introduce a set of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0006] According to a first aspect of the present disclosure, a computer-implemented method for performing application data consistency management between multiple computing devices within a communication network is provided. The method includes retrieving, by a first computing device among the multiple computing devices, application data from a second computing device among the multiple computing devices. The application data includes an application identification (ID) of an application residing (or executing) on ​​the second computing device and a first application version number. The first computing device updates a first database table using an object type associated with the application ID and the first application version number. The object type identifies a database table schema for a data object used by the application and a plurality of data fields of the data object. In response to the first computing device transmitting a notification of updated data fields in the plurality of data fields of the data object to a third computing device among the multiple computing devices, a second application version number is received from the third computing device. The second application version number is associated with the application residing (or executing) on ​​the third computing device. The first computing device selects, by the first computing device, one or more data fields from the updated data fields based on the second application version number. The first computing device transmits, by the first computing device, data stored in the one or more data fields in the updated data fields to the third computing device for synchronization.

[0007] In a first implementation form of the method according to the first aspect above, before updating the first database table, application code is executed by the first computing device to install the application with the first application version number at the first computing device.

[0008] In a second implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first database table is an application version history table that maps the first application version number to the object type and object type version number.

[0009] In a third implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first computing device updates a second database table based on the object type, wherein the second database table maps the object type version number to the object type and multiple data fields of the data object.

[0010] In a fourth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first computing device uses the first database table to determine an object type version number used by the application residing on the third computing device.

[0011] In a fifth implementation of the method according to the first aspect or any of the preceding implementations of the first aspect, the first computing device uses the object type version number used by the application residing on the third computing device and uses the second database table to determine the one or more data fields in the updated data fields.

[0012] In a sixth implementation of the method according to the first aspect or any preceding implementation of the first aspect, the first computing device transmits the data stored in the one or more data fields in the updated data field to the third computing device in response to a data download request from the third computing device, wherein the data download request includes the second application version number.

[0013] In a seventh implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the application data includes user information, and the user information identifies a user authorized to use the application on the second computing device.

[0014] In an eighth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first computing device performs verification of whether the user is authorized to use the application on the third computing device.

[0015] In a ninth implementation form of the method according to the first aspect or any preceding implementation form of the first aspect, the first computing device transmits the data stored in the one or more data fields in the updated data field to the third computing device when the verification is successful, and generates a notification when the verification is unsuccessful.

[0016] According to a second aspect of the present disclosure, a system for performing application data consistency management between multiple computing devices within a communication network is provided. The system includes a memory storing instructions and one or more processors in communication with the memory. The one or more processors execute the instructions to retrieve application data from a second computing device among the multiple computing devices, the application data including an application ID and a first application version number of an application residing (or executing) on ​​the second computing device. A first database table is updated using an object type associated with the application ID and the first application version number. The object type identifies a database table schema of a data object used by the application and multiple data fields of the data object. In response to transmitting a notification of updated data fields in the multiple data fields of the data object to a third computing device among the multiple computing devices, a second application version number is received from the third computing device. The second application version number is associated with the application residing (or executing) on ​​the third computing device. One or more of the updated data fields are selected based on the second application version number. Data stored by the one or more of the updated data fields is transmitted to the third computing device for synchronization.

[0017] In a first implementation form of the system according to the second aspect above, the first database table is an application version history table that maps the first application version number to the object type and the object type version number.

[0018] In a second implementation of the system according to the second aspect or any preceding implementation of the second aspect, the one or more processors execute the instructions to update a second database table based on the object type, wherein the second database table maps the object type version number to the object type and multiple data fields of the data object.

[0019] In a third implementation form of the system according to the second aspect or any of the foregoing implementation forms of the second aspect, the one or more processors execute the instructions to determine the object type version number used by the application residing on the third computing device, and the determination uses the first database table.

[0020] In a fourth implementation form of the system according to the second aspect or any of the foregoing implementation forms of the second aspect, the one or more data fields in the updated data fields are determined using the object type version number used by the application residing on the third computing device and using the second database table.

[0021] In a fifth implementation of the system according to the second aspect or any preceding implementation of the second aspect, the data stored in the one or more data fields in the updated data field is transmitted to the third computing device in response to a data download request from the third computing device. The data download request includes the second application version number.

[0022] According to a third aspect of the present disclosure, a non-transitory computer-readable medium storing instructions for performing application data consistency management between multiple computing devices within a communication network is provided. The instructions, when executed by one or more processors of a first computing device among the multiple computing devices, cause the one or more processors to perform operations. The operations include retrieving application data from a second computing device among the multiple computing devices. The application data includes an application ID and a first application version number of an application residing (or executing) on ​​the second computing device. A first database table is updated using an object type associated with the application ID and the first application version number. The object type identifies a database table schema for a data object used by the application and multiple data fields of the data object. In response to transmitting a notification of updated data fields in the multiple data fields of the data object to a third computing device among the multiple computing devices, a second application version number is received from the third computing device. The second application version number is associated with the application residing (or executing) on ​​the third computing device. One or more of the updated data fields are selected based on the second application version number. Data stored by the one or more of the updated data fields is transmitted to the third computing device for synchronization.

[0023] In a first implementation form of the non-transitory computer-readable medium according to the third aspect above, the first database table is an application version history table that maps the first application version number to the object type and the object type version number.

[0024] In a second implementation form of the non-transitory computer-readable medium according to the third aspect, upon execution, the instructions further cause the one or more processors to perform operations including: updating a second database table based on the object type, wherein the second database table maps the object type version number to the object type and a plurality of data fields of the data object.

[0025] In a third implementation form of the non-transitory computer-readable medium according to the third aspect above, once executed, the instructions also cause the one or more processors to perform operations including: determining the object type version number used by the application residing on the third computing device, and the determination uses the first database table.

[0026] In a fourth implementation form of the non-transitory computer-readable medium according to the third aspect above, once executed, the instructions also cause the one or more processors to perform operations including: determining the one or more data fields in the updated data fields, the determination using the object type version number of the object type used by the application residing on the third computing device and using the second database table.

[0027] In a fifth implementation form of the non-transitory computer-readable medium according to the third aspect, upon execution, the instructions further cause the one or more processors to perform operations including: transmitting the data stored in the one or more data fields in the updated data field to the third computing device in response to a data download request from the third computing device, wherein the data download request includes the second application version number.

[0028] In a sixth implementation form of the non-transitory computer-readable medium according to the third aspect above, the application data includes user information identifying a user authorized to use the application on the second computing device.

[0029] In a seventh implementation form of the non-transitory computer-readable medium according to the third aspect above, once executed, the instructions further cause the one or more processors to perform operations including: performing verification of whether the user is authorized to use the application on the third computing device.

[0030] In an eighth implementation form of the non-transitory computer-readable medium according to the third aspect, upon execution, the instructions further cause the one or more processors to perform operations including: transmitting data stored in the one or more data fields in the updated data field to the third computing device when the verification is successful, and generating a notification when the verification is unsuccessful.

[0031] According to a fourth aspect of the present disclosure, a system for performing application data consistency management between multiple computing devices within a communication network is provided. The system includes means for retrieving application data from a second computing device among the multiple computing devices. The application data includes an application ID and a first application version number of an application residing (or executing) on ​​the second computing device. The system includes means for updating a first database table using an object type associated with the application ID and the first application version number, the object type identifying a database table schema of a data object used by the application and a plurality of data fields of the data object. The system includes means for receiving a second application version number from a third computing device among the multiple computing devices in response to transmitting a notification of updated data fields in the plurality of data fields of the data object to a third computing device among the multiple computing devices, the second application version number being associated with the application residing (or executing) on ​​the third computing device. The system includes means for selecting one or more data fields in the updated data fields based on the second application version number. The system includes means for transmitting data stored in the one or more data fields in the updated data fields to the third computing device for synchronization.

[0032] In a first implementation form of the system according to the fourth aspect above, the first database table is an application version history table that maps the first application version number to the object type and the object type version number.

[0033] In a second implementation form of the system according to the fourth aspect, the system further comprises means for updating a second database table based on the object type, wherein the second database table maps the object type version number to the object type and a plurality of data fields of the data object.

[0034] In a third implementation form of the system according to the fourth aspect, the system further comprises means for determining an object type version number used by the application residing on the third computing device, the determination using the first database table.

[0035] In a fourth implementation form of the system according to the above-mentioned fourth aspect, the system also includes a device for using the object type version number used by the application residing on the third computing device and using the second database table to determine one or more data fields in the updated data fields.

[0036] Any of the foregoing examples can be combined with any one or more of the other foregoing examples to create new embodiments within the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components throughout the different views.The drawings illustrate generally by way of example and not limitation, various embodiments discussed herein.

[0038] Figure 1 is a high-level system overview of a network architecture using App Data Consistency Management (ADCM) functionality, according to some example embodiments.

[0039] Figure 2 is a block diagram illustrating a data object table used by different versions of an app executing on different computing devices within a communication network, according to some example embodiments.

[0040] Figure 3 is a block diagram illustrating initial app installation at multiple computing devices within a communication network and initial configuration of database tables for data consistency management, according to some example embodiments.

[0041] Figure 4 is a diagram showing, according to some example embodiments, Figure 3 A block diagram of an app upgrade within a communication network in FIG. 4 , wherein the app upgrade includes updating a database table for data consistency management.

[0042] Figure 5 is a block diagram illustrating a data object table used by different versions of an app executing on different computing devices within a communication network, according to some example embodiments.

[0043] Figure 6 is a block diagram illustrating initial app installation at multiple computing devices within a communication network and initial configuration of database tables for data consistency management, according to some example embodiments.

[0044] Figure 7 According to some embodiments, Figure 6 A block diagram of an app upgrade within a communication network in FIG. 4 , wherein the app upgrade includes updating a database table for data consistency management.

[0045] Figure 8 is a flow chart of a method suitable for performing application data consistency management among a plurality of computing devices within a communication network, according to some example embodiments.

[0046] Figure 9is a block diagram illustrating a representative software architecture that may be used in conjunction with the various device hardware described herein, according to some example embodiments.

[0047] Figure 10 is a block diagram illustrating circuits of devices implementing algorithms and performing methods, according to some example embodiments. DETAILED DESCRIPTION

[0048] First, it should be understood that although the following provides an exemplary implementation of one or more embodiments, Figures 1 to 10 The disclosed systems and / or methods described may also be implemented using any number of technologies, whether currently known or not yet in existence. The present disclosure should in no way be limited to the exemplary embodiments, drawings, and techniques described below, including the exemplary designs and exemplary implementations illustrated and described herein, but may be modified within the scope of the appended claims, along with all equivalents thereof.

[0049] In the following description, reference is made to the accompanying drawings, which form a part hereof, and in which are shown by way of example specific embodiments that may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the subject matter of the invention, and it is understood that other embodiments may be utilized and that structural, logical, and electrical changes may be made without departing from the scope of the present disclosure. Therefore, the following description of the example embodiments is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.

[0050] As used herein, the term "network-based service infrastructure" includes multiple network devices (also referred to as hosts, nodes, or servers) that provide on-demand computing capabilities (e.g., by performing data synchronization functions on one or more virtual machines or other virtual resources running on the network devices) and storage capabilities as a service to a community of end recipients (e.g., customers of the service infrastructure), where the end recipients are communicatively coupled to the network devices within the service infrastructure via a network. Customers of the service infrastructure can use one or more computing devices (also referred to as client devices or user devices) to access and manage services (including MBaaS) provided by the service infrastructure over the network. The client devices, network, and network-based service infrastructure can be collectively referred to as the "network architecture." Customers of the service infrastructure can also be referred to as "users."

[0051] As used herein, the term "schema" refers to the column layout of a database table, while the term "tuple" refers to the row layout (i.e., data) of a database table. As used herein, the term "object type (ObjectType)" identifies the type of a data object, such as a database table schema of a data object. As used herein, the term "object" (or "data object") refers to an abstraction (or mapping) of a database table tuple within the storage layer of a computing device. As used herein, the term "field" (or "data field") refers to an attribute of a data object. For example, "student" may be an object type that describes a student, while "studentID" may be a field in the object type "student."

[0052] As used herein, the term "application version" refers to the version of an application that resides or executes on a computing device. The application versions of the same app that reside or execute on different devices owned by the same user may be different. As used herein, the term "object type version" refers to the version of an object type used by a particular version of an app. Because updating an app does not necessarily include updating all object types (i.e., all types of data objects) used by the app, an object type can have its own version.

[0053] Applications can be configured to synchronize (or sync) data changes across devices in real time across different versions of the app. The techniques disclosed herein can be used for real-time app data synchronization between computing devices in a communication network (e.g., a wireless ad hoc network), where a network server (e.g., a cloud backend server in an MBaaS architecture) performs centralized coordination via an Application Data Consistency Management (ADCM) module.

[0054] In some aspects, a computing device executing an app stores an Object Type Table (OTT) that maps the type of data object used by the app (e.g., object type) to its data fields and a Data Object Table (DOT) for the data object. In other words, the object type identifies the database table schema for the data object used by the app. The DOT provides specific data (used by the app) for the data fields associated with the data object (of the object type identified by the OTT). In this regard, a DOT can be configured in the computing device for each object type identified by the OTT.

[0055] An ADCM module (e.g., an ADCM module with an MBaaS architecture) performs application data consistency management across multiple computing devices using the following tables: (a) an Application Version History Table (AVHT), which maps application versions to object types and versions of the object types; and (b) an Object Type Version History Table (OTVHT), which maps object type versions to object types and their data fields.

[0056] When each computing device is executing an app (associated with an app ID and application version), the ADCM module maintains an application version history (in the AVHT) and an object type version history (in the OTVHT). The ADCM module synchronizes data from one or more data object tables to each computing device based on the version of the app being executed by the computing device and using the AVHT and OTVHT. When the model is upgraded (for example, when an app is updated on a computing device, causing the object type used by the app to be updated), the data object on the device is upgraded to a higher version (associated with the upgraded app), and the data stored in the data object is synchronized by the ADCM module using the AVHT and OTVHT. During the data synchronization process, only the incremental data object changes are used for synchronization, resulting in more efficient real-time synchronization of app data.

[0057] The data synchronization functions discussed herein may be performed by the ADCM module and may include configuring one or more of OTT, AVHT, and OTVHT at each computing device within the communication network. More specifically, in one example embodiment (e.g., in conjunction with a peer-to-peer network), the ADCM module may be configured at each computing device (e.g., as Figure 9 The ADCM module may be part of the device operating system (not shown) or may be installed as an application. In another example embodiment, the ADCM module may be configured to execute only at a centralized network server (e.g., network synchronization server 116) that is accessible by multiple computing devices. Once the app is installed at a computing device, the ADCM module at the centralized network server detects the app download or installation (e.g., through the transmission of a synchronization request or a notification message from the device) and causes the OTT and DOT to be generated at the computing device. The ADCM module also generates AVHT and OTVHT at the centralized network server to perform the data synchronization functions discussed herein.

[0058] Some benefits of the disclosed app data consistency management technology include minimal latency in data communication and synchronization between devices (e.g., smartphones, tablets, laptops, etc.) running different application versions. App updates on one device do not require updates on other connected devices running the same app. App updates can be stopped and restarted from the stopped state. Even in the absence of an MBaaS network, app updates and application data consistency management can be fully supported on a peer-to-peer (P2P) network, where each device can be configured to operate as if it were a device coupled to an MBaaS architecture with ADCM capabilities.

[0059] Figure 1 Provides a high-level system overview of a network architecture using App Data Consistency Management (ADCM) functionality, according to some example embodiments. Figure 1 , a network architecture 100 may include a plurality of devices (e.g., user devices) 102A, ..., 102N (collectively referred to as devices 102) that are communicatively coupled to a network-based service infrastructure (e.g., an MBaaS architecture) 114 via a network 112. Devices 102A, ..., 102N are associated with a user 111 and may be configured to interact with the network-based service infrastructure 114 using a network access client, such as one of clients 110A, ..., 110N. For clarity, devices 102A, ..., 102N may be collectively referred to as devices 102. Network access clients 110A, ..., 110N may be implemented as web clients or application (app) clients.

[0060] Devices 102A, ..., 102N (also collectively referred to as devices 102) also include corresponding apps 104A, ..., 104N, OTTs 106A, ..., 106N, and DOTs 108A, ..., 108N. Apps 104A, ..., 104N can be different versions of an app (or the same version). Each of OTTs 106A, ..., 106N maps the type of data object (or object type) used by a corresponding one of apps 104A, ..., 104N to its data fields. Each of DOTs 108A, ..., 108N provides specific data (used by the app) for the data fields associated with the data object of the object type identified by the corresponding OTT.

[0061] User 111 may be a human user (e.g., a human), a machine user (e.g., a computer configured by a software program to interact with device 102 and network-based service infrastructure 114), or any appropriate combination thereof (e.g., a person assisted by a machine or a machine supervised by a person). User 111 is not part of network architecture 100 but is associated with device 102 (e.g., user 111 may be the owner of device 102) (and may be a user of device 102). For example, device 102 may include a desktop computer, a vehicle computer, a tablet computer, a navigation device, a portable media device, or a smartphone belonging to user 111. User 111 may use devices 102A, ..., 102N to access services to which the user is subscribing (e.g., MBaaS-related services including application data consistency management services) provided by ADCM module 122 within network-based service infrastructure 114. In this regard, user 111 may also be referred to as a "customer 111" or "tenant 111" of network-based service infrastructure 114.

[0062] The network 112 can be any network capable of enabling communication between or between machines, databases, and devices (e.g., devices 102A, ..., 102N and network synchronization servers 116, ..., 118 within the MBaaS architecture 114). Accordingly, the network 112 can be a wired network, a wireless network (e.g., a mobile network or a cellular network), or any suitable combination thereof. The network 112 can include one or more portions that constitute a private network, a public network (e.g., the Internet), or any suitable combination thereof.

[0063] The network-based service infrastructure 114 may include a plurality of computing devices (eg, network synchronization servers 116 , . . . , 118 ). Figure 1 The network synchronization server 116 is shown in greater detail and includes an MBaaS ADCM module 122 and an ADCM application programming interface (API) 120 .

[0064] The MBaaS ADCM module 122 includes suitable circuitry, logic, interfaces, and / or code configured to manage application data consistency across multiple computing devices, such as the devices 102A, ..., 102N of the user 111, that are communicatively coupled to the MBaaS architecture 114. More specifically, the MBaaS ADCM module 122 maintains the DOTs 128, ..., 130 (containing data objects used by the apps 104A, ..., 104N executing on the devices 102A, ..., 102N), the AVHT 124 (which maps application versions to object types and object type versions), and the OTVHT 126 (which maps object type versions to object types and their fields). Furthermore, the MBaaS ADCM module 122 synchronizes data stored by the data objects in the DOTs 128, ..., 130 to one or more of the devices 102A, ..., 102N based on the application version resident or executing on each device and using the AVHT 124 and OTVHT 126. Combine Figure 2 and Figure 5 A more detailed description of DOT is provided. Figure 3 and Figure 4 Provides a more detailed description of application data consistency management performed by the MBaaS ADCM module 122. Figure 6 and Figure 7 A more detailed description of application data consistency management performed by the ADCM module within devices in a P2P network is provided.

[0065] Figure 1 Any of the devices shown in can be implemented in a general-purpose computer that is modified (e.g., configured or programmed) by software to be a special-purpose computer to perform the functions described herein for the machine, database, or device. As used herein, a "database" is a data storage resource that stores data, where the data is structured as a text file, a table, a spreadsheet, a relational database (e.g., an object-relational database, a NoSQL database, a network database, or a graph database), a triple store, a hierarchical data store, or any appropriate combination thereof. In addition, data accessed (or stored) via an application programming interface (API) or a remote procedure call (RPC) can be considered to be accessed from (or stored to) a database. In addition, Figure 1 Any two or more of the devices or databases shown in the may be combined into a single machine, database, or device, and the functionality described herein for any single machine, database, or device may be subdivided among multiple machines, databases, or devices.

[0066] Figure 2 is a block diagram 200 illustrating a data object table used by different versions of an app executed on different computing devices within a communication network, according to some example embodiments. Figure 2 , device 202 may be executing a first version of an app that uses a DOT 208 having data fields “ID” and “Name.” For example, the first version of the app executed on device 202 uses an object type “Student” that has data fields “ID” and “Name” that describe a “Student” data object, and DOT 208 provides data associated with the data fields of the data object.

[0067] Device 206 may be executing a second version of the app that uses a DOT 212 with data fields "ID," "Name," "Age," and "State." For example, the second version of the app executed on device 206 uses an upgraded version of the object type "Student," which has data fields "ID" and "Name" (appearing in DOT 208) and additional (new) fields "Age" and "State," forming the upgraded DOT 212 for the "Student" data object. MBaaS architecture 204 is configured with a DOT 210 that is identical to the DOT used by the latest version of the app (e.g., the upgraded DOT 212 for the "Student" data object used by the app executed on device 206). The MBaaS ADCM module of MBaaS architecture 204 uses the application data consistency management techniques discussed herein to synchronize data (e.g., data from one or more of the data fields in DOT 210) between multiple devices (e.g., device 202 and device 206) executing the same or different versions of the app.

[0068] Figure 3 is a block diagram 300 illustrating initial app installation at multiple computing devices within a communication network and initial configuration of database tables for data consistency management, according to some example embodiments. Figure 3 Also shown are app data consistency management operations 1 to 6 indicated by circled numbers.

[0069] refer to Figure 3 , devices 304 and 306 and MBaaS architecture 308 form a communication network, such as an ad hoc wireless network or other type of network. Device 304 is configured with OTT 310 and DOT 312. Device 306 is configured with OTT 320 and DOT 322. MBaaS architecture 308 includes an ADCM module (not shown) configured with AVHT 314, OTVHT 316, and DOT 318. Figure 3 middle).

[0070] At operation 1, the app store 302 installs the app 303 at, for example, the device 304. For example, the application code of the app 303 is downloaded at the device 304, and the ADCM module executes the application code to install the app 303. The app 303 is associated with an application identification (ID) and an application version number (e.g., application version 1). The installation of the app 303 at the device 304 results in the generation of an OTT 310 that specifies the object types used by the app 303. More specifically, the app 303 uses the object type "student" having data fields student ID and student name and the object type "school" having data fields school ID and school name. The installation of the app 303 on the device 304 also results in the generation of a corresponding DOT that has data objects of the object types specified by the OTT 310. For example, Figure 3 The device 304 is shown configured with a DOT 312 for a data object of type "Student." More specifically, the DOT 312 provides data for the data fields Student ID and Student Name of the data object of type "Student."

[0071] In an example embodiment, app store 302 installs app 303 at one or more additional devices (e.g., device 306) associated with a user of device 304. Installing app 303 on device 306 results in the generation of OTT 320, which specifies the object types used by app 303 at device 306. More specifically, app 303 uses object type "student" with data fields student ID and student name and object type "school" with data fields school ID and school name. Installing app 303 on device 306 also results in the generation of a corresponding DOT with data objects of the object types specified by OTT 320. For example, Figure 3 The device 306 is shown to be configured with a DOT 322 for a data object of type "student". More specifically, the DOT 322 provides data for the data fields studentID and studentname of the data object of type "student". Figure 3 Device 304 and device 306 are shown configured with DOT 312 and DOT 322 for data objects of type "student", but other DOTs may be configured for data objects of other object types used by app 303 (eg, DOTs for data objects of type "school").

[0072] In an example embodiment, after app 303 is installed on device 304, application data is transmitted to MBaaS framework 308 (or MBaaS framework 308 retrieves application data from device 304 based on notification that app 303 was installed on device 304). The application data from device 304 includes the application ID and application version number of app 303. In some aspects, the application data also includes user information identifying the user authorized to use the app on device 304 (e.g., the user of device 304 who initiated the download and installation of app 303 from app store 302). The ADCM module in MBaaS framework 308 uses the application data to determine whether the user has already downloaded and installed app 303 on another device.

[0073] If device 304 is the only device with app 303, the ADCM module installs app 303 in MBaaS architecture 308 (e.g., on a network synchronization server hosting the ADCM module) and configures AVHT 314, OTVHT 316, and DOT 318 to synchronize the database table schema for each data object used by app 303 at device 304. If the ADCM module determines that the user has downloaded and installed app 303 on another device (e.g., device 306), the ADCM module verifies whether the app 303 installed at device 306 is the same version as the app 303 installed in MBaaS architecture 308. If the app 303 at device 306 is a different version than the app 303 installed in MBaaS architecture 308, the ADCM module synchronizes the database table schema for the data objects (e.g., the object types specified by AVHT 314 and OTVHT 316) to match the database table schema for the data objects used by the version of app 303 installed at device 306.

[0074] Figure 3AVHT, OTVHT, and DOT configurations are shown at the MBaaS architecture 308 when app 303 of the same application version (e.g., application version 1) is installed at a network synchronization server hosting an ADCM module (e.g., ADCM module 122) in the MBaaS architecture 308, at device 304, and at device 306. After the MBaaS architecture 308 receives application data from device 304, the ADCM module installs app 303 on the network synchronization server in the MBaaS architecture 308 and determines (e.g., based on the application data) the object type associated with app 303. For example, the ADCM module determines that app 303 uses the object type "Student" with data fields of student ID and student name, and the object type "School" with data fields of school ID and school name.

[0075] The ADCM module then configures the AVHT 314 to map the application version number (e.g., application version 1) to object types and object type versions. In some aspects, when an application is upgraded, the object type may or may not be upgraded. In this regard, the object type version may indicate different versions of the same object type, where the different versions have one or more different data fields. To account for the possibility of the same object type having different versions used by different versions of the same application, the ADCM module also configures the OTVHT 316, which maps object type versions to corresponding object types and their data fields. For example, the OTVHT 316 maps object type version 1 of the object type "student" to the data fields "studentID" and "studentName" of the data object. Similarly, the OTVHT 316 also maps object type version 1 of the object type "school" to the data fields "schoolID" and "schoolName" of the data object.

[0076] At operation 2, new data (e.g., (01; Tom) and (02; Alex)) is entered into DOT 312 for a data object of type "Student." At operation 3, the new data added to DOT 312 is synchronized with MBaaS framework 308 and added to DOT 318, thereby updating the corresponding data fields of the DOT. At operation 4, notification of the updated data fields of DOT 318 is transmitted to device 306. At operation 5, device 306 transmits a data download request to the ADCM module of MBaaS framework 308, including the application version number of app 303 installed on device 306.

[0077] At operation 6, the ADCM module of the MBaaS framework 308 checks the AVHT 314 against the application version number received from the device 306 to determine the object types and object type versions used by the application version. The ADCM module uses the OTVHT 316 to determine the data fields associated with each of the object types used by the application version executed on the device 306. The ADCM module determines which data fields of the updated data fields of the DOT 318 are used by the DOT 322 and transmits the data stored in these data fields in the DOT 318 to the device 306 for synchronization (e.g., updates the DOT 322 with the transmitted data).

[0078] In an exemplary embodiment, the ADCM module in the MBaaS architecture 308 uses the application data (including user information) to perform verification to verify whether the user is authorized to use the application on one or more attached devices (e.g., device 306). Furthermore, when verification is successful, the data stored in the data field in the DOT 318 is transferred to the device 306 for synchronization. If verification is unsuccessful, the ADCM module generates a notification that the user is not authorized to access the device 306 and synchronization is suspended.

[0079] Figure 4 According to some embodiments, Figure 3 Block diagram 400 of an app upgrade within a communication network in FIG. 4 , the app upgrade including updating a database table for data consistency management. Figure 4 Also shown are application data consistency management operations 7 to 13 indicated by circled numbers.

[0080] refer to Figure 4 , device 304 is configured with OTT 402 and DOT 404. Device 306 is configured with OTT 412 and DOT 414. MBaaS architecture 308 includes an ADCM module (not shown) configured with AVHT 406, OTVHT 408 and DOT 410. Figure 4 middle).

[0081] At operation 7, app store 302 installs app 305 (which is an upgraded version 2 of app 303) on device 304. App 305 is associated with an app ID (which is the same as the app ID of app 303) and an application version number (e.g., app version 2). The installation of app 305 on device 304 causes the object type "student" to be updated to include an additional data field, student age, while the object type "school" remains unchanged without changing any data fields. As a result, OTT 310 is updated to OTT 402 to reflect the updated data fields used by the object type "student."

[0082] In an example embodiment, after app 305 is installed on device 304, the application data is transmitted to MBaaS framework 308 (or MBaaS framework 308 retrieves the application data from device 304 based on notification that app 305 has been installed on device 304). The application data from device 304 includes the application ID and application version number of app 305. In some aspects, the application data also includes user-related information associated with the user of device 304 (e.g., the user of device 304 who initiated the download and installation of app 305 from app store 302). The ADCM module in MBaaS framework 308 uses the application data to determine whether the user has already downloaded and installed app 305 on another device.

[0083] If device 304 is the only device with app 305, and the database tables of the ADCM module in MBaaS architecture 308 have not been updated based on the object types used by app 305, then at operation 8, device 304 synchronizes the updated object type "student" (and any other updated object types in OTT 402) with the database tables configured by the ADCM module within MBaaS architecture 308. More specifically, AVHT 314 is updated to AVHT 406 by including database table entries for the object types "student" and "school" associated with application version 2. For example, AVHT 406 indicates that the same object type version 1 is used for object type "school" in application version 2, but object type version 2 is used for object type "student" in application version 2 (which corresponds to the updated DOT 404 having three data fields). Furthermore, OTVHT 316 is updated to OTVHT 408 by including a database table entry for object type version 2 for object type "student," mapping to its three corresponding data fields (student ID, student name, and student age). DOT 318 is also updated to include all three data fields for a data object of type "Student".

[0084] At operation 9, new data is inserted into DOT 404 at device 304. More specifically, data for field Student ID 03 and data for field Student Age (for Student ID 01 and Student ID 02) are added to DOT 404. At operation 10, the new data added to DOT 404 is synchronized with MBaaS architecture 308 and added to DOT 410, updating the corresponding data fields of the DOT. At operation 11, notification of the updated data fields of DOT 410 is transmitted to device 306. At operation 12, device 306 transmits a data download request to the ADCM module of MBaaS architecture 308, the request including the application version number (e.g., application version 1) of app 303 installed at device 306.

[0085] At operation 13, the ADCM module of the MBaaS architecture 308 checks the AVHT 406 against the application version number received from the device 306 to determine the object types and object type versions used by the application version at the device 306. Since the device 306 is currently executing the previous version of the app (application version 1), object type version 1 corresponding to application version 1 is used for synchronization. The ADCM module then uses the OTVHT 408 to determine the data fields associated with each of the object types used by the application version executed on the device 306. The ADCM module then determines that the student ID and student name data fields in the updated data fields of the DOT 410 are used by the DOT 414 and transmits the data stored by these data fields in the DOT 410 (i.e., 03; JOHN) to the device 306 for synchronization (e.g., updating the DOT 414 with the transmitted data). At this point, only the added data object changes are used for data synchronization, thereby more efficiently synchronizing app data in real time. In other words, only the data used by the corresponding application version is being transmitted, and data associated with data fields not used by the application version is not transmitted for synchronization.

[0086] Figure 5 is a block diagram illustrating a data object table used by different versions of an app executed on different computing devices within a communication network 500, according to some example embodiments. Figure 5 , the communication network 500 is a P2P communication network formed by devices 502 , 504 , 506 and 508 . Figure 5Also shown are the DOTs used by the apps executing on devices 502, 504, and 506. More specifically, device 502 may be executing a first version of the app that uses a DOT 510 having data fields "ID" and "Name." For example, the first version of the app executing on device 502 uses an object type "Student" that has data fields "ID" and "Name" that describe a "Student" data object, and DOT 510 provides data associated with the data fields of the data object. Figure 5 It is also shown that each of devices 502 to 508 is configured with additional tables, such as OTVHT, AVHT, and Device Application Version Table (DAVT). More specifically, devices 502, 504, 506, and 508 are configured with corresponding additional tables 516, 518, 520, and 522. The functions of the additional tables will be combined with Figure 6 Have a discussion.

[0087] Device 504 may be executing a second version of the app that uses a DOT 512 with data fields “ID,” “Name,” and “Age.” For example, the second version of the app executing on device 504 uses an upgraded version of the object type “Student,” which has data fields “ID” and “Name” (appearing in DOT 510) and an additional (new) field “Age,” thereby forming a DOT 512 for the upgraded “Student” data object.

[0088] Device 506 may be executing a third version of the app that uses a DOT 514 with data fields “ID,” “Name,” “Age,” and “State.” For example, the third version of the app executing on device 506 uses an upgraded version of the object type “Student,” which has data fields “ID,” “Name,” and “Age” (appearing in DOT 512) and an additional (new) field “State,” thereby forming DOT 514 for the upgraded “Student” data object.

[0089] Compared to the network architecture 100, the P2P communication network 500 does not include a network entity (such as the MBaaS ADCM module 122 configured on the network synchronization server 116) for coordinating application data consistency management between multiple computing devices. Instead, each of the devices 502, 504, 506, and 508 within the P2P communication network 500 will be configured with its own ADCM module, which has database tables for app data consistency management, including AVHT, OTVHT, and DOT. In addition, each of the devices 502, 504, 506, and 508 within the P2P communication network 500 is also configured with a device application version table (DAVT), which indicates the version number of the application executed within each device within the P2P network 500. In combination Figure 6 and Figure 7 Provides a more detailed description of application data consistency management among multiple computing devices within a P2P communication network.

[0090] Figure 6 is a block diagram 600 illustrating initial app installation at multiple computing devices within a communication network (eg, a P2P communication network) and initial configuration of database tables for data consistency management, according to some example embodiments. Figure 6 Also shown are app data consistency management operations 1 to 5 indicated by circled numbers.

[0091] refer to Figure 6 , devices 604 and 606 form a P2P communication network. Device 604 is equipped with AVHT 608, DOT 610, OTVHT 612, and DAVT 614. Device 606 is equipped with AVHT 616, DOT 618, OTVHT 620, and DAVT 622. Figure 6 The AVHT, DOT and OTVHT database tables shown in FIG have the same Figure 3 DAVT 614 and DAVT 622 are configured to store application version numbers of apps executed at each device within the P2P network.

[0092] At operation 1, app store 602 installs app 603 (with application version 1) at device 604. For example, the application code for app 603 is downloaded at device 604, and the ADCM module within the device executes the application code to install app 603. App 603 is associated with an application ID and an application version number (e.g., application version 1). The installation of app 603 at device 604 results in the generation of AVHT 608 (mapping the application version number to the object type and object type version number used by the app) and OTVHT 612 (mapping the object type version number to the object type and data fields within the data object associated with the object type).

[0093] like Figure 6 As shown, app 603 executed on device 604 uses the object type "student" with data fields student ID and student name and the object type "school" with data fields school ID and school name. Installing app 603 on device 604 also results in the generation of a corresponding DOT with data objects of the object type specified by OTVHT 612. For example, Figure 6 The device 604 is shown configured with a DOT 610 for a data object of type "student." More specifically, the DOT 610 provides data for the data fields Student ID and Student Name of the data object of type "student."

[0094] In an example embodiment, app store 602 installs app 603 at one or more additional devices (e.g., device 606) within a P2P network associated with a user of device 604. Installation of app 603 on device 606 results in the generation of AVHT 616 (mapping application version numbers to object types and object type version numbers used by the app) and OTVHT 620 (mapping object type version numbers to the object type and data fields within the data objects associated with the object type).

[0095] like Figure 6 As shown, app 603 executed on device 606 uses the object type "student" with data fields student ID and student name and the object type "school" with data fields school ID and school name. Installing app 603 on device 606 also results in the generation of a corresponding DOT with data objects of the object type specified by OTVHT 620. For example, Figure 6 The device 606 is shown configured with a DOT 618 for a data object of type "student." More specifically, the DOT 618 provides data for the data fields Student ID and Student Name of the data object of type "student."

[0096] At operation 2, new data (e.g., (01; Tom) and (02; Alex)) is entered in DOT 610 for a data object of type "Student". At operation 3, notification of the updated data fields of DOT 610 is transmitted to device 606. At operation 4, device 606 transmits a data download request to the ADCM module of device 604, the request including the application version number of app 603 installed at device 606. In some aspects, the ADCM module updates DAVT table 614 with the application version number of the app executed on device 606 received with the data download request.

[0097] At operation 5, the ADCM module of the device 604 checks the AVHT 608 against the application version number received from the device 606 to determine the object types and object type versions used by the application version. The ADCM module then uses the OTVHT 612 to determine the data fields associated with each of the object types used by the application version executed on the device 606. The ADCM module also determines which data fields in the updated data fields of the DOT 610 are used by the DOT 618 at the device 606 and transmits the data stored by these data fields in the DOT 610 to the device 606 for synchronization (e.g., updates the DOT 618 with the transmitted data).

[0098] Figure 7 According to some embodiments, Figure 6 A block diagram 700 of an app upgrade within a P2P communication network includes updating a database table for data consistency management. Figure 7 Also shown are app data consistency management operations 6 to 10 indicated by circled numbers.

[0099] refer to Figure 7 , device 604 is configured with AVHT 702, DOT 704, OTVHT 706 and DAVT 708. Device 606 is configured with AVHT 710, DOT 712, OTVHT 714 and DAVT 716. Figure 7 The AVHT, DOT and OTVHT database tables shown in FIG have the same Figure 4 and Figure 6 DAVT 708 and DAVT 716 are configured to store application version numbers of apps executed at each device within the P2P network.

[0100] At operation 6, app store 602 installs app 605 (which is an upgraded application version 2 of app 603) at device 604. App 605 is associated with an app ID (which is the same as the app ID of app 603) and an application version number (e.g., application version 2). The installation of app 605 on device 604 causes the object type "student" to be updated to include an additional data field, student age, while the object type "school" remains unchanged with no changes made to any of its data fields. Therefore, AVHT 608 is updated to AVHT 702 to reflect the updated data fields used by object type "student" (e.g., object type "student" for object type version 2 and object type "school" for object type version 1 are mapped for application version 2). OTVHT 612 is updated to OTVHT 706, which includes a new entry that maps object type version 2 of object type "student" to the data fields of the updated data object.

[0101] like Figure 7 As shown, device 606 has not been upgraded to application version 2 and remains at application version 1 (executing app 603 ). Therefore, AVHT 710 and OTVHT 714 remain consistent with AVHT 616 and OTVHT 620 .

[0102] At operation 7, new data is inserted into DOT 704 at device 604. More specifically, data for the field student ID 03 (e.g., data (03; JOHN; 18)) and data for the field student age (for student ID 01 and student ID 02) are added to DOT 704. At operation 8, notification of the updated data fields of DOT 704 is transmitted to device 606. At operation 9, device 606 transmits a data download request to the ADCM module of device 604, the request including the application version number of app 603 installed at device 606 (e.g., application version 1).

[0103] At operation 10, the ADCM module of device 604 checks AVHT 702 against the application version number received from device 606 to determine the object types and object type versions used by the application version at device 606. Since device 606 is currently executing a previous version of the app (e.g., application version 1), object type version 1 corresponding to application version 1 is used for synchronization. The ADCM module then uses OTVHT 706 to determine the data fields associated with each of the object types used by the application version executing on device 606. The ADCM module then determines that the student ID data field and the student name data field in the updated data fields of DOT 704 are used by app 603 at device 606, and transmits the data stored by these data fields in DOT 704 (i.e., data (03; JOHN)) to device 606 for synchronization (e.g., updating DOT 712 with the transmitted data).

[0104] Figure 8 800 is a flow chart of a method 800 for performing application data consistency management between multiple computing devices within a communication network, according to some example embodiments. The method 800 includes operations 802, 804, 806, and 808. By way of example and not limitation, the method 800 may be performed by the ADCM module 122, which is configured to: Figure 1 The method 800 is executed within the network synchronization server 116 in the MBaaS architecture 114 shown, or the method 800 can be executed by another ADCM module (e.g., as in conjunction with Figures 5 to 7 ADCM module in question).

[0105] refer to Figure 8 At operation 802, a first computing device among a plurality of computing devices retrieves application data from a second computing device among the plurality of computing devices. The application data includes an application identification (ID) of an application executed on the second computing device and a first application version number. At operation 804, the first computing device updates a first database table (e.g., AVHT). The update may be performed using an object type associated with the application ID and the first application version number. The object type identifies a database table schema of a data object used by the application and a plurality of data fields of the data object.

[0106] At operation 806, the first computing device receives a second application version number from a third computing device. In some embodiments, the second application version number is received in response to a notification transmitted by the first computing device to a third computing device among the plurality of computing devices regarding updated data fields in a data object. For example, the second application version number is associated with an application executing on the third computing device and is received as part of a data download request in response to the notification. At operation 808, one or more of the updated data fields are selected by the first computing device for synchronization. In some embodiments, the one or more data fields are selected based on the second application version number. Data stored by the one or more of the updated data fields is transmitted by the first computing device to the third computing device for synchronization.

[0107] Figure 9 is a block diagram illustrating a representative software architecture 900 that may be used in conjunction with the various device hardware described herein, according to some example embodiments. Figure 9 is only a non-limiting example of a software architecture 902, and it should be understood that many other architectures may be implemented to facilitate the functionality described herein. The software architecture 902 may be executing on hardware such as Figure 10 1000, which includes, among other things, a processor 1005, memory 1010, storage 1015 and 1020, and I / O interfaces 1025 and 1030. Representative hardware layers 904 are shown and may represent, for example, Figure 10 The computing device 1000 in FIG. The representative hardware layer 904 includes one or more processing units 906 with associated executable instructions 908. The executable instructions 908 represent executable instructions of the software architecture 902, including Figures 1 to 8 The hardware layer 904 also includes a memory and / or storage module 910, which also has executable instructions 908. The hardware layer 904 may also include other hardware 912, which represents any other hardware of the hardware layer 904, such as other hardware shown as part of the computing device 1000.

[0108] exist Figure 9 In the example architecture of FIG, software architecture 902 can be conceptualized as a stack of layers, where each layer provides specific functionality. For example, software architecture 902 can include layers such as operating system 914, library 916, framework / middleware 918, application 920, and presentation layer 944. In operation, application 920 and / or other components within each layer can call application programming interface (API) calls 924 through the software stack and receive responses, return values, etc., shown as messages 926 in response to API calls 924. Figure 9The layers shown are representative in nature, and not all software architectures 902 have all layers. For example, some mobile operating systems or specialized operating systems may not provide framework / middleware 918, while other operating systems may provide such layers. Other software architectures may include additional or different layers.

[0109] The operating system 914 can manage hardware resources and provide common services. The operating system 914 can include, for example, a kernel 928, services 930, drivers 932, and an ADCM module 960. The kernel 928 can serve as an abstraction layer between the hardware and other software layers. For example, the kernel 928 can be responsible for memory management, processor management (e.g., scheduling), component management, networking, security settings, etc. The services 930 can provide other common services to other software layers. The drivers 932 can be responsible for controlling or interfacing with the underlying hardware. For example, the drivers 932 can include a display driver, a camera driver, Drivers, Flash drivers, Serial communication drivers (for example, Universal Serial Bus (USB) drivers), drivers, audio drivers, power management drivers, and so on, depending on the hardware configuration.

[0110] In some aspects, the ADCM module 960 can be combined with Figures 1 to 8 The ADCM modules discussed are identical to any of the ADCM modules discussed (and are combined with Figures 1 to 8 Any of the ADCM modules discussed perform the same functions), such as ADCM module 122 , which includes an application version history table 124 , an object type version history table 126 , and data object tables 128 , . . . , 130 .

[0111] The libraries 916 may provide a common infrastructure that can be utilized by the applications 920 and / or other components and / or layers. The functionality provided by the libraries 916 generally allows other software modules to perform tasks more easily than directly interfacing with underlying operating system 914 functions (e.g., kernel 928, services 930, drivers 932, and / or ADCM modules 960). The libraries 916 may include system libraries 934 (e.g., C standard libraries) that may provide functions such as memory allocation functions, string manipulation functions, mathematical functions, etc. In addition, the libraries 916 may include API libraries 936, such as media libraries (e.g., libraries for supporting the rendering and manipulation of various media formats such as MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.), graphics libraries (e.g., OpenGL frameworks that can be used to render 2D and 3D graphics content on a display), database libraries (e.g., SQLite that can provide various relational database functions), web libraries (e.g., WebKit that can provide web browsing functionality), etc. The library 916 may also include various other libraries 938 to provide numerous other APIs to the applications 920 and other software components / modules.

[0112] The framework / middleware 918 (sometimes also referred to as middleware) can provide a higher-level common infrastructure that can be utilized by the application programs 920 and / or other software components / modules. For example, the framework / middleware 918 can provide various graphical user interface (GUI) functions, advanced resource management, advanced location services, etc. The framework / middleware 918 can provide a wide range of other APIs that can be utilized by the application programs 920 and / or other software components / modules, some of which can be specific to a particular operating system 914 or platform.

[0113] Applications 920 include built-in applications 940 and / or third-party applications 942. Representative examples of built-in applications 940 may include, but are not limited to, a contacts application, a browser application, a book reader application, a location application, a media application, a messaging application, and / or a game application. Third-party applications 942 may include any of the built-in applications 940 as well as a wide variety of other applications. In a specific example, third-party applications 942 (e.g., applications created by entities other than the vendor of a particular platform using Android TM or iOS TM Software Development Kit (SDK) applications can be developed on mobile operating systems such as iOS TM 、Android TM 、 In this example, third-party applications 942 can call API calls 924 provided by a mobile operating system such as operating system 914 to facilitate the functionality described herein.

[0114] Applications 920 can create a user interface to interact with users of the system by utilizing built-in operating system functionality (e.g., kernel 928, services 930, drivers 932, and / or ADCM modules 960), libraries (e.g., system libraries 934, API libraries 936, and other libraries 938), and framework / middleware 918. Alternatively or additionally, in some systems, interaction with the user can occur through a presentation layer, such as presentation layer 944. In these systems, the application / module "logic" can be separated from the aspects of the application / module that interact with the user.

[0115] Some software architectures utilize virtual machines. Figure 9 In the example of , this is illustrated by virtual machine 948. A virtual machine creates a software environment where applications / modules can be run as if they were running on a hardware machine (such as, for example, Figure 10 The virtual machine 948 is executed by the host operating system ( Figure 9 The virtual machine 948 is hosted by an operating system 914 in a virtual machine and typically, but not always, has a virtual machine monitor 946 that manages the operation of the virtual machine 948 and the interface with the host operating system (i.e., the operating system 914). The software architecture 902 executes within the virtual machine 948, such as an operating system 950, libraries 952, framework / middleware 954, applications 956, and / or a presentation layer 958. These layers of the software architecture executed within the virtual machine 948 may be the same as or different from the corresponding layers previously described.

[0116] Figure 10 is a block diagram illustrating circuitry for implementing algorithms and devices for performing methods, according to some example embodiments. Not all components need be used in various embodiments. For example, a client, server, and cloud-based network device may each use a different set of components or, in the case of a server, a larger storage device.

[0117] One example computing device in the form of a computer 1000 (also referred to as computing device 1000, computer system 1000, or computer 1000) may include a processor 1005, memory 1010, removable storage 1015, non-removable storage 1020, input interface 1025, output interface 1030, and communication interface 1035, all connected by a bus 1040. Although the example computing device is illustrated and described as being a computer 1000, the computing device may take different forms in different embodiments.

[0118] Memory 1010 may include volatile memory 1045 and non-volatile memory 1050 and may store programs 1055. Computer 1000 may include, or have access to, a computing environment that includes, various computer-readable storage media, such as volatile memory 1045, non-volatile memory 1050, removable storage 1015, and non-removable storage 1020. Computer storage includes random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD ROM), digital versatile discs (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium capable of storing computer-readable instructions.

[0119] Computer-readable instructions stored on a computer-readable medium (e.g., a program 1055 stored in memory 1010) can be executed by the processor 1005 of the computer 1000. Hard drives, CD-ROMs, and RAM are some examples of articles of manufacture that include non-transitory computer-readable media such as storage devices. The terms "computer-readable medium" and "storage device" do not include carrier waves, as carrier waves are considered too ephemeral. "Computer-readable non-transitory media" include all types of computer-readable media, including magnetic storage media, optical storage media, flash memory media, and solid-state storage media. It should be understood that the software can be installed in a computer and sold with the computer. Alternatively, the software can be acquired and loaded into the computer, including acquiring the software through a physical medium or distribution system (including, for example, from a server owned by the software creator or from a server that the software creator does not own but uses). For example, the software can be stored on a server for distribution over the Internet. As used herein, the terms "computer-readable medium" and "machine-readable medium" are interchangeable.

[0120] The program 1055 may utilize one or more modules discussed herein, such as the ADCM module 1060. In some aspects, the ADCM module 1060 may be combined with Figures 1 to 8Any of the ADCM modules discussed are identical (and perform the same functions), such as ADCM module 122 , which includes an application version history table 124 , an object type version history table 126 , and data object tables 128 , . . . , 130 .

[0121] In an example embodiment, computer 1000 includes means for retrieving application data from a first computing device among a plurality of computing devices, the application data including an application identification (ID) and a first application version number of an application executing on the first computing device. Computer 1000 also includes means for updating a first database table using object type information associated with the application ID and the first application version number, the object type information identifying a database table schema of a data object used by the application and a plurality of data fields of the data object. Computer 1000 also includes means for synchronizing the data object using synchronization data for the plurality of data fields received from a second computing device to generate a synchronized data object. Computer 1000 also includes means for receiving a second application version number from the second computing device in response to a notification of the synchronized data object transmitted to the second computing device, the second application version number associated with the application executing on the second computing device. Computer 1000 also includes means for selecting one or more data fields of the plurality of data fields of the synchronized data object based on the second application version number, and means for transmitting data stored by the one or more data fields of the plurality of data fields to the second computing device for synchronization. In some embodiments, the computer 1000 may include other or additional modules for performing any one or combination of the steps described in the embodiments. In addition, any of the additional or alternative embodiments or aspects of the method, as shown in any of the drawings or recited in any of the claims, are also contemplated to include similar modules.

[0122] Any one or more of the modules described herein may be implemented using hardware (e.g., a processor of a machine, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or any suitable combination thereof). In addition, any two or more of these modules may be combined into a single module, and the functionality described herein for a single module may be subdivided across multiple modules. Furthermore, according to various example embodiments, modules described herein as being implemented within a single machine, database, or device may be distributed across multiple machines, databases, or devices.

[0123] Although certain embodiments have been described in detail above, other modifications are possible. For example, the logic flows depicted in the accompanying drawings do not require the particular order or sequential sequence shown to achieve the desired results. Other steps may be provided or eliminated from the described flows, and other components may be added to or removed from the described systems. Other embodiments may be within the scope of the claims.

[0124] It should also be understood that software comprising one or more computer-executable instructions that facilitate the processes and operations described above in connection with any or all of the steps of the present disclosure can be installed in and sold with one or more computing devices consistent with the present disclosure. Alternatively, the software can be acquired and loaded into one or more computing devices, including through physical media or a distribution system (including, for example, from a server owned by the creator of the software or from a server not owned by the creator of the software but used by the creator of the software). For example, the software can be stored on a server for distribution over the Internet.

[0125] In addition, it will be understood by those skilled in the art that the application of the present disclosure is not limited to the details of the structure and arrangement of the components outlined in the specification or shown in the drawings. The embodiments herein can have other embodiments and can be implemented or executed in various ways. In addition, it should be understood that the wording and terminology used herein are for illustration and should not be considered as restrictive. "Including," "comprising," or "having" and their variations used herein are intended to cover the items listed thereafter and their equivalents as well as additional items. Unless otherwise limited, the terms "connect," "couple," and "install" and their variations herein are used in a broad sense and cover direct and indirect connections, couplings, and installations. In addition, the terms "connect" and "couple," and their variations are not limited to physical or mechanical connections or couplings. In addition, terms such as upward, downward, bottom, and top are relative and are used to assist in explanation, but are not restrictive.

[0126] According to the illustrated embodiments, components of the illustrative apparatus, systems, and methods employed may be implemented at least in part in digital electronic circuitry, analog electronic circuitry, or computer hardware, firmware, software, or a combination thereof. These components may be implemented, for example, as a computer program product, such as a computer program, program code, or computer instructions tangibly embodied in an information carrier or machine-readable storage device, for execution by a data processing apparatus, such as a programmable processor, a computer, or multiple computers, or to control the operation of the data processing apparatus.

[0127] The computer program can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or another unit suitable for use in a computing environment. The computer program can be deployed to execute the computer program on one or more computers at one site, or distributed across multiple sites and interconnected by a communication network. In addition, the functional programs, codes, and code segments for completing the technology described herein can be easily interpreted by those skilled in the art to which the technology described herein belongs as being within the scope of the claims. The method steps associated with the illustrative embodiments can be performed by one or more programmable processors executing computer programs, codes, or instructions to perform functions (e.g., by operating on input data and / or generating output). The method steps can also be performed by dedicated logic circuitry, and the apparatus for performing the method can be implemented as a dedicated logic circuitry, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0128] The illustrative logical blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, a digital signal processor (DSP), an ASIC, an FPGA, or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination of the above devices designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

[0129] Processors suitable for executing computer programs include, for example, general-purpose and special-purpose microprocessors, as well as any one or more processors of any type of digital computer. Typically, the processor will receive instructions and data from read-only memory or random access memory, or both. The required elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or the computer will also be operatively coupled to receive data from or transfer data to the one or more mass storage devices. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including, for example, semiconductor memory devices, such as electrically programmable read-only memory or ROM (Electrically Erasable Programmable ROM, EPROM), electrically erasable programmable ROM (EEPROM), flash memory devices, and data storage disks (e.g., magnetic disks, internal hard disks, removable disks, magneto-optical disks, CD-ROMs, or DVD-ROMs). The processor and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0130] Those skilled in the art will appreciate that any of a variety of different technologies and techniques may be used to represent information and signals. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0131] As used herein, a “machine-readable medium” (or “computer-readable medium”) refers to a device capable of storing instructions and data, either temporarily or permanently, and may include, but is not limited to, random access memory (RAM), read-only memory (ROM), buffer memory, flash memory, optical media, magnetic media, cache memory, other types of storage (e.g., erasable programmable read-only memory (EEPROM)), and / or any suitable combination thereof. The term “machine-readable medium” should be understood to include a single medium or multiple media (e.g., a centralized or distributed database, or associated caches and servers) that can store processor instructions. The term “machine-readable medium” should also be understood to include any medium (or combination of multiple media) that can store instructions for execution by one or more processors 1005, such that the instructions, when executed by one or more processors 1005, cause the one or more processors 1005 to perform one or more of the methods described herein. Accordingly, a “machine-readable medium” refers to a single storage device or device, as well as a “cloud-based” storage system or storage network comprising multiple storage devices or devices. The term “machine-readable medium” as used herein does not include the signal itself.

[0132] In addition, without departing from the scope of the present disclosure, the techniques, systems, subsystems, and methods described and illustrated in various embodiments as discrete or separate can be combined or integrated with other systems, modules, techniques, or methods. Other items shown or discussed as coupled to each other or directly coupled to or in communication with each other can be indirectly coupled or in communication through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and modifications are ascertainable by those skilled in the art and can be made without departing from the scope of the present disclosure.

[0133] Although the present disclosure has been described with respect to specific features and embodiments thereof, it will be apparent that various modifications and combinations thereof may be made without departing from the scope of the present disclosure. For example, other components may be added to or removed from the system. Accordingly, the specification and drawings are to be considered simply as illustrations of the present disclosure as defined by the appended claims, and are intended to cover any modifications, variations, combinations, or equivalents that fall within the scope of the present disclosure. Other aspects may be within the scope of the claims.

Claims

1. A computer-implemented method for performing application data consistency management between a plurality of computing devices within a communication network, characterized in that: The method comprises: retrieving, by a first computing device among the plurality of computing devices, application data from a second computing device among the plurality of computing devices, the application data comprising an application identification ID and a first application version number of an application residing on the second computing device; The first computing device updates a first database table using an object type associated with the application ID and the first application version number, the object type identifying a database table schema of a data object used by the application and a plurality of data fields of the data object, the first database table being an application version history table mapping the first application version number to the object type and the object type version number; and the first computing device updates a second database table based on the object type, the second database table mapping the object type version number to the object type and the plurality of data fields of the data object; and In response to transmitting, by the first computing device, to a third computing device among the plurality of computing devices, a notification of an updated data field among the plurality of data fields of the data object: receiving, by the first computing device, from the third computing device, a second application version number associated with the application residing on the third computing device; selecting, by the first computing device, one or more of the updated data fields based on the second application version number; and Data stored by the one or more of the updated data fields is transmitted by the first computing device to the third computing device for synchronization.

2. The computer-implemented method of claim 1, wherein: The method further comprises: Before updating the first database table, application code is executed by the first computing device to install the application with the first application version number at the first computing device.

3. The computer-implemented method of claim 1 , wherein: The method further comprises: The first computing device determines a version number of an object type used by the application program residing on the third computing device, the determining using the first database table.

4. The computer-implemented method of claim 3, wherein: The method further comprises: The one or more of the updated data fields are determined by the first computing device, the determining using the object type version number used by the application resident on the third computing device and using the second database table.

5. The computer-implemented method according to any one of claims 1 to 4, characterized in that: The method further comprises: The data stored by the one or more of the updated data fields is transmitted by the first computing device to the third computing device in response to a data download request from the third computing device, the data download request including the second application version number.

6. The computer-implemented method of claim 1, wherein: The application data includes user information identifying a user authorized to use the application on the second computing device.

7. The computer-implemented method of claim 6, wherein: The method further comprises: Verification of whether the user is authorized to use the application on the third computing device is performed by the first computing device.

8. The computer-implemented method of claim 7, wherein: The method further comprises: transmitting, by the first computing device to the third computing device, the data stored in the one or more data fields in the updated data field, wherein the transmitting is performed when the verification is successful; and A notification is generated by the first computing device when the authentication is unsuccessful.

9. A system for performing application data consistency management between multiple computing devices within a communication network, characterized in that The system comprises: a memory for storing instructions; and one or more processors of a first computing device of the plurality of computing devices in communication with the memory, wherein the one or more processors execute the instructions to: retrieving application data from a second computing device among the plurality of computing devices, the application data comprising an application identification ID and a first application version number of an application residing on the second computing device; updating a first database table using an object type associated with the application ID and the first application version number, the object type identifying a database table schema of a data object used by the application and a plurality of data fields of the data object, the first database table being an application version history table mapping the first application version number to the object type and the object type version number; and updating a second database table based on the object type, the second database table mapping the object type version number to the object type and the plurality of data fields of the data object; and In response to transmitting a notification of an updated data field in the plurality of data fields of the data object to a third computing device among the plurality of computing devices: receiving a second application version number from the third computing device, the second application version number being associated with the application resident on the third computing device; selecting one or more of the updated data fields based on the second application version number; and The data stored by the one or more of the updated data fields is transmitted to the third computing device for synchronization.

10. The system according to claim 9, characterized in that The one or more processors execute the instructions to perform the following operations: An object type version number used by the application resident on the third computing device is determined, the determining using the first database table.

11. The system according to claim 10, wherein: The one or more processors execute the instructions to perform the following operations: The one or more of the updated data fields are determined using the object type version number used by the application residing on the third computing device and using the second database table.

12. The system according to any one of claims 9 to 11, characterized in that The one or more processors execute the instructions to perform the following operations: The data stored by the one or more of the updated data fields is transmitted to the third computing device, the transmitting being in response to a data download request from the third computing device, the data download request including the second application version number.

13. A computer-readable medium storing computer instructions for performing application data consistency management between a plurality of computing devices within a communication network, characterized in that: When the instructions are executed by one or more processors of a first computing device among the plurality of computing devices, the one or more processors are caused to perform operations including: retrieving application data from a second computing device among the plurality of computing devices, the application data comprising an application identification ID and a first application version number of an application residing on the second computing device; updating a first database table using an object type associated with the application ID and the first application version number, the object type identifying a database table schema of a data object used by the application and a plurality of data fields of the data object, the first database table being an application version history table mapping the first application version number to the object type and the object type version number; and updating a second database table based on the object type, the second database table mapping the object type version number to the object type and the plurality of data fields of the data object; and In response to transmitting a notification of an updated data field in the plurality of data fields of the data object to a third computing device among the plurality of computing devices: receiving a second application version number from the third computing device, the second application version number being associated with the application resident on the third computing device; selecting one or more of the updated data fields based on the second application version number; and The data stored by the one or more of the updated data fields is transmitted to the third computing device for synchronization.

14. The computer-readable medium of claim 13, wherein: The instructions further cause the one or more processors to: An object type version number used by the application resident on the third computing device is determined, the determining using the first database table.

15. The computer-readable medium of claim 14, wherein: The instructions further cause the one or more processors to: The one or more of the updated data fields are determined using the object type version number used by the application residing on the third computing device and using the second database table.

16. The computer-readable medium according to any one of claims 13 to 15, wherein: The instructions further cause the one or more processors to: The data stored by the one or more of the updated data fields is transmitted to the third computing device, the transmitting being in response to a data download request from the third computing device, the data download request including the second application version number.

17. The computer-readable medium of claim 13, wherein: The application data includes user information identifying a user authorized to use the application on the second computing device.

18. The computer-readable medium of claim 17, wherein: The instructions further cause the one or more processors to: Verification is performed to determine whether the user is authorized to use the application on the third computing device.

19. The computer-readable medium of claim 18, wherein: The instructions further cause the one or more processors to: transmitting the data stored in the one or more data fields in the updated data field to the third computing device, wherein the transmitting is performed when the verification is successful; as well as A notification is generated when the verification is unsuccessful.

20. A system for performing application data consistency management between multiple computing devices within a communication network, characterized in that The system comprises: means for retrieving application data from a second computing device among the plurality of computing devices, the application data comprising an application identification ID and a first application version number of an application residing on the second computing device; means for updating a first database table using an object type associated with the application ID and the first application version number, the object type identifying a database table schema of a data object used by the application and a plurality of data fields of the data object, the first database table being an application version history table mapping the first application version number to the object type and object type version number; and means for updating a second database table based on the object type, the second database table mapping the object type version number to the object type and a plurality of data fields of the data object; means for receiving a second application version number from a third computing device among the plurality of computing devices in response to transmitting a notification of an updated data field among the plurality of data fields of the data object to a third computing device among the plurality of computing devices, the second application version number being associated with the application resident on the third computing device; means for selecting one or more of the updated data fields based on the second application version number; and Means for transmitting data stored by the one or more of the updated data fields to the third computing device for synchronization.

21. The system according to claim 20, wherein: The system further comprises: Means for determining a version number of an object type used by the application resident on the third computing device, the determining using the first database table.

22. The system according to claim 21, wherein: The system further comprises: Means for determining the one or more of the updated data fields, the determining using the object type version number used by the application resident on the third computing device and using the second database table.

Images