Trigger of system creation update by applying rule to client update of shared record

Abstract

To provide a medium, a system, and a method that manage a shared data record to which multiple clients have simultaneous access and editing rights.SOLUTION: A method for providing an update to a shared data record is to, when the shared data record is changed, send the change to all clients currently accessing the shared data record so that the current version of the shared data record is provided to each client. However, applying certain rules to the latest data record before sending it to each client may cause additional changes. Therefore, in response to such request rule-based changes, the latest shared data record is provided to each client that has access rights to the shared data record.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] Technical Field The present disclosure relates to recording and displaying changes to a single record based on multiple user inputs. In particular, the present disclosure relates to triggering system-generated updates to shared records by applying rules to changes to shared records from multiple users.

Background Art

[0002] Background To enable two or more users to share and modify a document or data record, software providers generally rely on one of three approaches for controlling the editing of data records. The first approach allows one user to edit a data record by locking it, and all other users must enter a queue and wait their turn to apply desired changes, using a lock restriction. In this case, since only one user can edit a data record at a given time, changes must be applied sequentially.

[0003] The second approach uses check-out and check-in restrictions that perform manual conflict resolution before merging any conflicting changes to the data record. The third approach, generally used for simple document collaboration, uses data transformation to synchronize the view of the data record.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The approaches described in this section are approaches that can be achieved, but are not necessarily the approaches that could have been envisioned or achieved heretofore. Thus, unless otherwise indicated, none of the approaches described in this subsection should be assumed to be eligible as prior art merely by virtue of being included in this section.

[0005] Embodiments are shown by way of example and are not limited by the accompanying drawings. In the present disclosure, when referring to "an" or "one" embodiment, it does not necessarily refer to the same embodiment, but means at least one embodiment.

Brief Description of the Drawings

[0006]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0007] Detailed Description In the following description, for the purposes of explanation, a complete understanding is provided by describing a number of specific details. Even without these specific details, one or more embodiments can be implemented. Features described in one embodiment may be combined with features described in another embodiment. In some examples, well-known structures and devices are described with reference to block diagrams so as not to unnecessarily obscure the present invention.

[0008] 1. Overall Overview 2. System Architecture 2.1 Data Record Management Server 2.2 Cooperative Data Record Management among Multiple Clients 3. Cooperative Data Record Management of Shared Data Records 3.1 Receiving Update / Change Requests 3.2 Resolving Pending Changes 3.3 Integrating Changes 3.4 Applying Specific Rules to Shared Data Records 3.5 Relaying Updates to Specific Clients Accessing the Shared Data Record 4. Exemplary Embodiments 4.1 Providing the Latest Shared Data Record Based on an Update Request 4.2 Providing Differences for Updating Shared Data Records Based on Change Requests 5. Computer Networks and Cloud Networks 6. Other Extensions 7. Hardware Overview 1. Overall Overview One or more embodiments determine and apply system-generated updates to shared records accessible by each client among a set of clients. The system determines an update to a shared record that (a) is not requested by any of the set of clients that can access the shared record, but (b) is triggered by applying rules to at least one client-requested update. The system can apply rules to a modified record that incorporates the client-requested update. Alternatively or additionally, the system can apply rules to a stand-alone version of the client-requested update. The system distributes a final modified record that incorporates both the client-requested update and the system-generated update to one or more clients among the set of clients. The final modified record can further incorporate pending changes stored in a common ledger. Distributing the final modified record to a client may include distributing a set of differences from the version of the shared record accessible to the client. Alternatively or additionally, distributing the final modified record may include distributing the entire final modified record.

[0009] One or more embodiments described herein and / or recited in the claims may not be included in this overall summary.

[0010] 2. System Architecture 2.1 Data Record Management Server FIG. 1 shows a system 100 according to one or more embodiments. As shown in FIG. 1, the system 100 includes clients 102 that communicate with a data record management server 124. The data record management server 124 includes several components including a change integration engine 106 and a client record comparison engine 114. The data record management ser Bar 124 is configured to communicate with a data repository (DB) 118, a common ledger 120, and a client cache 116 stored in a computer-readable storage medium. These components may be incorporated into the data record management server 124 within the system 100 or into separate components in various ways. In one or more embodiments, the system 100 may include more or fewer components than those shown in FIG. 1. The components shown in FIG. 1 may be local or remote to each other. The components shown in FIG. 1 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into one application and / or machine. Operations described with respect to one component may be performed by another component or shared among multiple components.

[0011] Additional embodiments and / or examples regarding computer networks that may be used for communication between the various components of FIG. 1 are described in Section 5 below, "Computer Networks and Cloud Networks."

[0012] In one or more embodiments, the data repository 118 may be any type of storage unit and / or device (e.g., a file system, a database, a set of tables, or any other storage mechanism) for storing data. Also, the data repository 118 may include a plurality of different storage units and / or devices. The plurality of different storage units and / or devices may be of the same or different types and may be located at the same or different physical sites. Further, the data repository 118 may be implemented or executed on the same computing system as the data record management server 124 or the client 102, or alternatively or additionally, the data repository 118 may be implemented or executed on a computing system separate from the data record management server 124 or the client 102. The data repository 118 may be communicatively coupled to the data record management server 124 and / or the client 102 via a direct connection, a wireless connection, a network, or other connections apparent to those skilled in the art.

[0013] In one or more embodiments, the common ledger 120 is configured to store individual entries of each change and / or update made to the shared data records managed by the data record management server 124. The common ledger 120 can store outstanding changes to the shared data records (changes and / or updates that have not yet been reflected in the version of the shared data records being viewed by the client 102). In one implementation example, the common ledger 120 stores a log of changes made to a particular shared data record by each particular client having access rights to the particular shared data record managed by the data record management server 124.

[0014] In one embodiment, the common ledger 120 may be stored in any type of computer-readable storage medium and / or storage device, such as a hard disk drive, an optical disk drive, a flash memory, a non-volatile random access memory (NVRAM), a parameter random access memory (PRAM), or any other storage medium known in the art. Also, in one approach, the common ledger 120 may have any format, data structure, or hierarchical configuration, as is known to those skilled in the art. The common ledger 120 may be located at the same or a different physical site than the data record management server 124, the client cache 116, the data repository 118, or the client 102.

[0015] In one approach, the common ledger 120 may be implemented or stored on the same computing system as the data record management server 124 or the client 102. Alternatively or additionally, the common ledger 120 may be implemented or stored on a separate and / or remote computing system from the data record management server 124 or the client 102. The common ledger 120 may be communicatively coupled to the data record management server 124 via a direct connection, a wireless connection, a network, or any other connection that would be apparent to those skilled in the art.

[0016] In one or more embodiments, the client cache 116 is configured to store at least the difference between each shared data record managed by the data record management server 124 and each version of the shared data record accessed by the client 102 and any other client communicating with the data record management server 124.

[0017] In one embodiment, the client cache 116 can store outstanding updates and / or changes to shared data records accessible to the client 102. In this embodiment, the client cache 116 stores a list of all updates / changes made to each shared data record accessible to the client 102 and an indicator indicating the current version of each shared data record accessible to the client 102.

[0018] In a further embodiment, the client cache 116 may be a global cache that stores outstanding updates and / or changes to all shared data records managed by a data record management server 124 accessible to a plurality of clients including the client 102. In this embodiment, the client cache 116 stores a list of all updates / changes made to each shared data record accessible to the plurality of clients and an indicator indicating the current version of each shared data record accessed by each of the plurality of clients.

[0019] In one or more embodiments, the client cache 116 may be stored in any type of computer-readable storage medium and / or storage device, such as a hard disk drive, optical disk drive, flash memory, NVRAM, PRAM, or any other storage medium known in the art. Also, in one approach, the client cache 116 may have any format, data structure, or hierarchical configuration, as known to those skilled in the art. The client cache 116 may be located at the same or a different physical site than the data record management server 124, the common ledger 120, the data repository 118, or the client 102.

[0020] In one approach, the client cache 116 may be implemented or stored on the same computing system as the data record management server 124 or the client 102. Alternatively or additionally, the client cache 116 may be implemented or stored on a separate and / or remote computing system from the data record management server 124 or the client 102. The client cache 116 may be communicatively coupled to the data record management server 124 via a direct connection, via a wireless connection, via a network, or via other connections apparent to those skilled in the art.

[0021] In one embodiment, the data record management server 124 is implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device may refer to a physical device that runs an application or a virtual machine. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, hardware devices with specific functions, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile phones, smartphones, personal digital assistants (PDAs), wireless receivers and / or transmitters, base stations, communication management devices, routers, switches, controllers, access points, and / or client devices. In an alternative embodiment, the data record management server 124 may be partially or fully implemented as a software component operating within a hardware environment.

[0022] In one embodiment, as described above, client 102 is implemented on one or more digital devices. In an alternative embodiment, client 102 may be implemented partially or fully as a software component that runs within a hardware environment.

[0023] In various examples, client 102 may be a desktop computer, a laptop computer, a tablet computer, a smartphone, a server, a dedicated client device that operates with data record management server 124, or other hardware devices that can communicate with data record management server 124.

[0024] In one or more embodiments, an interface may be implemented in hardware and / or software to facilitate communication between client 102 and data record management server 124. The interface can provide user interface elements and accept input via the user interface elements. Examples of interfaces include a graphical user interface (GUI), a command line interface (CLI), a tactile interface, and a voice command interface. Examples of user interface elements include check boxes, radio buttons, drop-down lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0025] In one embodiment, different components of the interface may be specified in different languages. The behavior of each user interface element may be specified in a dynamic programming language such as JavaScript (registered trademark). The content of the user interface element is specified in a markup language such as Hypertext Markup Language (HTML), Extensible Markup Language (XML), or XML User Interface Language (XUL). Also, the layout of the user interface element may be specified in a style sheet language such as Cascading Style Sheets (CSS). Alternatively, the interface may be specified in one or more other languages such as Java (registered trademark), C, or C++.

[0026] In one embodiment, client 102 sends a request ("REQ") 104 to data record management server 124. In one approach, request 104 may be a change request that includes one or more updates or changes to a particular shared data record stored in data repository 118 and managed by data record management server 124. In another approach, request 104 may be an update request to trigger data record management server 124 to respond with an updated version of the shared data record.

[0027] According to another embodiment, data record management server 124 may periodically execute the functions described herein in response to a trigger event (e.g., , another client requests an update / change to the shared data record, device startup, network change) according to a predetermined schedule even if request 104 is not sent from client 102.

[0028] In response to receiving request 104, data record management server 124 sends request 104 to change integration engine 106. Change integration engine 106 may be implemented in hardware and / or software and is configured to perform certain functions and / or logic in response to a trigger event such as receiving request 104. Also, change integration engine 106 is configured to communicate with client cache 116, common ledger 120, and data repository 118.

[0029] In one embodiment, change integration engine 106 determines a first set of differences between the version of the shared data record being accessed by client 102 and any changes indicated in request 104. In one approach, the first set of differences may be included in request 104. As will be understood by those skilled in the art, this difference may affect any part or all of the shared data record and may include any type of modification, deletion, addition, and / or adjustment to the shared data record.

[0030] In one embodiment, change integration engine 106 integrates any updates and / or changes requested from request 104 with any updates and / or changes that have not been applied to the shared data record requested by other sources or triggered by one or more events. Other sources may include, but are not limited to, common ledger 120 and client cache 116.

[0031] Updates and / or changes that have not yet been applied to the shared data record are referred to as pending updates. In an intelligent manner, an integrated update of the shared data record is created by integrating all of these pending updates with any updates and / or changes requested from request 104. Applying this integrated update to the shared data record causes all of the pending updates and / or changes and the requested updates and / or changes to be cumulatively reflected in the shared data record, bringing the shared data record up to date.

[0032] In one approach, as will be described in more detail below, the change integration engine 106 can simplify the pending updates and the updates and / or changes requested from the request 104 before generating the integrated update.

[0033] The change integration engine 106 generates a first revised data record ("RDR1") 108 by applying the integrated update to the version of the shared data record being accessed by the client 102. In one approach, this version of the shared data record reflects all of the pending updates and any updates and / or changes requested from the request 104 as a full or complete data record. Once the first revised data record 108 is generated, the change integration engine 106 sends the first revised data record 108 to the rule application engine 110 for further processing.

[0034] In an alternative approach, the change integration engine 106 can reduce the resource usage when transferring data by sending only the differences between the first revised data record 108 and the version of the shared data record being accessed by the client 102.

[0035] The rule application engine 110 may be implemented in hardware and / or software and is configured to execute certain functions and / or logic in response to a trigger event such as the receipt of the first revised data record 108 or the receipt of the differences between the first revised data record 108 and the version of the shared data record being accessed by the client 102. Also, the rule application engine 110 is configured to communicate with the client record comparison engine 114 and the data repository 118.

[0036] ​The rule application engine 110 is configured to determine a second update to the shared data record by applying a set of rules (which may include one or more rules, conditions, equivalences, equations, operations, processes, etc.) to the first modified data record 108. This second update is predicted based on any changes to the version of the shared data record that is being accessed by the client 102 to account for these changes to the underlying original shared data record. That is, the second update is required to apply the first update. Also, the application of the second update is not requested by the client 102 or any other client having access rights to the shared data record. Instead, the rule application engine 110 determines whether the first modified data record 108 complies with the set of rules described above. If the first modified data record 108 does not comply with the set of rules described above, the rule application engine 110 generates a second update. Applying this second update to the first modified data record 108 causes the first modified data record 108 to comply with the set of rules described above.

[0037] The set of rules described above may include, for example, operations for checking the first modified data record 108, operations for manipulating and / or changing the first modified data record 108, and operations for undoing or rolling back changes to the first modified data record 108. Some exemplary operations include, but are not limited to, determining the executability of a requested configuration, calculating a price, calculating inventory, configuring a product, and determining a quote for a configured product based on multiple price calculations.

[0038] When the set of rules described above is applied to the first modified data record 108 (if appropriate), a second update of the shared data record is generated to correct any defects, errors, mistakes, etc. that may exist in the first modified data record 108 due to changes made to the shared data record by the client 102. If there are no changes to the first modified data record 108 as a result of the application of the rules by the rule application engine 110, this second update is not required. In this case, the rule application engine 110 does not modify the first modified data record 108 and sends it to the client record comparison engine 114.

[0039] In one example, the shared data record may be an estimate of a configured product, the set of rules described above may include pricing and estimation instructions based on the configured product, and the client 102 may reconfigure the product to remove features. In this example, the set of rules applied by the rule application engine 110 to the first modified data record 108 can analyze the configured product (including indicators of the removed features) and provide a revised total price of the configured product excluding the price or cost associated with the removed features described by the first modified data record 108.

[0040] In another example, the shared data record may be a complex server rack system configuration specified by a customer via the client 102, and the set of rules described above may include server rack system configuration instructions to ensure that the components and options specified by the shared data record are executable and interoperable with other choices. If the client 102 adds hardware such as a top-of-rack (ToR) switch to the server rack, the rule application engine 110 may perform the following operations on the first modified data record 108. The set of rules applied to the data record 108 can analyze the modified complex server rack system configuration (including the added ToR switch) to determine whether the configuration is appropriate based on the overall system requirements and other selected components. In this example, the rule application engine 110 can change the specific ToR switch model selected by the client 102 to a different ToR switch model that is compatible with other components within the previously specified composite server rack system configuration, and modify the composite server rack system configuration to include a more appropriate ToR switch.

[0041] In one or more embodiments, the rule application engine 110 can store the second update, the first modified data record 108, and / or the second modified data record 112 in the data repository 118. Also, in order to apply the rules to the shared data record when the change integration engine 106 sends only the differences rather than the complete modified data record to the rule application engine 110, the rule application engine 110 can access the version of the shared data record accessed by the client 102 from the data repository 118 to generate the first modified data record 108 by applying the first update before applying the set of rules described above.

[0042] When the second update is generated by the rule application engine 110, it is applied to the first modified data record 108 to generate a second modified data record ("RDR2") 112. Then, the rule application engine 110 sends the second modified data record 112 to the client record comparison engine 114. As described above, when the application of the rules does not require a second update, the rule application engine 110 sends the first modified data record 108 to the client record comparison engine 114.

[0043] The client record comparison engine 114 may be implemented in hardware and / or software and is configured to perform certain functions and / or logic in response to a trigger event, such as the receipt of a first modified data record 108 or the receipt of a second modified data record 112. Also, the client record comparison engine 114 is configured to communicate with the client cache 116 and the client 102.

[0044] In one or more embodiments, the client record comparison engine 114 is configured to determine the differences between two versions of the shared data record by comparing the second modified data record 112 with the version of the shared data record being accessed by the client 102. Once these differences are determined, a response ("RESP") 122 indicating these differences may be sent to the client 102 to conserve resources.

[0045] The client record comparison engine 114 can access the version of the shared data record being accessed by the client 102 from the client cache 116. The client cache 116 stores a copy resulting from a previous interaction with the client 102 that requested access to the shared data record. An entry storing or indicating this version of the shared data record is created in the client cache 102 for future reference.

[0046] In one embodiment, the client record comparison engine 114 can store in the client cache 116 the second modified data record 112 and / or the differences between the determined second modified data record 112 and the version of the shared data record being accessed by the client 102 for future reference.

[0047] In another approach, the response 122 sent to the client 102 may include the determined second modified data record 112 instead of the difference between the determined second modified data record 112 and the version of the shared data record being accessed by the client 102. In this or any other approach, the client record comparison engine 114 can store the second modified data record 112 in the client cache 116 for future reference.

[0048] 2.2 Cooperative Data Record Management among Multiple Clients FIG. 2 shows a system 200 according to one or more embodiments. The components described above in connection with FIG. 1 may be implemented in another exemplary environment shown in FIG. 2. The system 200 shown in FIG. 2 includes a plurality of clients (Client A 202, Client B 226,..., Client N 228), and each client communicates with a data record management server 230. The data record management server 230 in FIG. 2 is configured in the same manner as the data record management server 124 in FIG. 1, except that it includes a data repository 118 and a common ledger 120. Also, the data record management server 230 includes a plurality of client caches (Client A cache 220, Client B cache 222,..., Client N cache 224). However, these components do not necessarily have to be included in the data record management server 230 and may be separate components in one or more embodiments.

[0049] Each shared data record may be accessed simultaneously by two or more of the plurality of clients, and each particular client among the plurality of clients has the right to edit one or more shared data records hosted by the data record management server 230.

[0050] In one embodiment, each of various client caches (e.g., client A cache 220, client B cache 222, ..., client N cache 224) can individually store, for each client, at least the difference between the shared data records managed by the data record management server 230 and the versions of the shared data records accessed by a specific client (e.g., client A 202, client B 226, ..., client N 228).

[0051] In this embodiment, each client cache designated for each client can store outstanding updates and / or changes to the shared data records accessible to each client (e.g., client A cache 220 stores the outstanding updates and / or changes of client A 202). In this embodiment, client A cache 220 stores a list including all updates / changes made to each shared data record accessible to client A 202, and an indicator indicating each current version of each shared data record accessed by client A 202.

[0052] In an alternative embodiment, a single global client cache can provide the functions of the various client caches shown in FIG. 2.

[0053] In one or more embodiments, each client cache may be stored in any type of computer-readable storage medium and / or storage device, such as a hard disk drive, an optical disk drive, a flash memory, NVRAM, PRAM, or any other storage medium known in the art. Also, in one approach, the client cache may have any format, data structure, or hierarchical configuration, as is known to those skilled in the art.

[0054] In one embodiment, one or more client caches (e.g., client A cache 220, client B cache 222, ..., client N cache 224) may be located at the same physical site as the data record management server 230, the common ledger 120, the data repository 118, or various clients (e.g., client A 202, client B 226, ..., client N 228). Also, in one embodiment, one or more client caches (e.g., client A cache 220, client B cache 222, ..., client N cache 224) need not be located at the same physical site as the data record management server 230, the common ledger 120, the data repository 118, or various clients (e.g., client A 202, client B 226, ..., client N 228).

[0055] Any of the components shown and described in FIG. 2 may be incorporated into the data record management server 230 in various ways or may operate as a separate component within the system 200.

[0056] In one or more embodiments, the system 200 may include more or fewer components than those shown in FIG. 2. The components shown in FIG. 2 may be local or remote from each other. The components shown in FIG. 2 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into one application and / or machine. Operations described with respect to one component may be performed by another component or may be shared among multiple components.

[0057] Additional embodiments and / or examples regarding computer networks that may be used for communication between the various components of FIG. 2 are described in Section 5 "Computer Networks and Cloud Networks" below.

[0058] In one embodiment, the data record management server 230 is implemented on one or more digital devices. In an alternative embodiment, the data record management server 230 may be partially or fully implemented as a software component operating within a hardware environment.

[0059] In one embodiment, as described above, one or more of the plurality of clients (e.g., client A202) may be implemented on one or more digital devices. In an alternative embodiment, client A202 (or any other client) may be partially or fully implemented as a software component executing within a hardware environment.

[0060] In one or more embodiments, an interface may be implemented in hardware and / or software to facilitate communication between the plurality of clients and the data record management server 230.

[0061] The data record management server 230 includes an event queue 206, which receives requests from a plurality of clients, stores various requests, and distributes the requests to the request modification and integration engine 106 according to some predetermined method, for example, in the order received, first in first out (FIFO), first in last out (FILO), or last in first out (LIFO), or according to the priority specified by the request or determined by the event queue 206. As will be apparent to those skilled in the art, any method, technique, or manner for determining the order for relaying the received requests may be employed in the event queue 206.

[0062] In one embodiment, the event queue 206 can send requests from a plurality of clients to the common ledger 120. Thereby, the common ledger 120 can store requests or portions thereof (e.g., differences between data records, requested updates / changes) for future reference.

[0063] In one or more embodiments, the event queue 206 may be stored in any type of computer-readable storage medium and / or storage device, such as a hard disk drive, an optical disk drive, flash memory, NVRAM, PRAM, or any other storage medium known in the art. Also, in one approach, the event queue 206 may have any format, data structure, or hierarchical configuration, as known to those skilled in the art.

[0064] When a client sends a change request, for example, when client A202 sends a change request ("REQ") 204 to the data record management server 230, this request 204 is placed in the event queue 206. As described with reference to FIG. 1, this request is provided to the change integration engine 106 for processing according to the manner adopted in the event queue 206 (or, if no manner exists, in the order received).

[0065] As shown in FIG. 2, based on the updates / changes within request 204 from client A202, the change integration engine 106 generates a first update and applies the first update to the shared data record of the version being accessed by client A202, thereby generating a first revised data record ("RDR1") 208. In various ways, the shared data record of the version being accessed by client A202 may be included in request 204, retrieved from data repository 118, retrieved from client A cache 220, and / or retrieved from common ledger 120. As described with reference to FIG. 1, the change integration engine 106 sends the first revised data record 208 to the rule application engine 110 for further processing.

[0066] Referring again to FIG. 2, in an alternative approach, the change integration engine 106 can reduce the resource usage when transferring data by sending only the differences between the first revised data record 208 and the shared data record of the version being accessed by client A202 to the rule application engine 110.

[0067] The rule application engine 110 is configured to determine a second update 210 of the shared data record by applying a set of rules (which may include one or more rules, conditions, equivalences, equations, operations, processes, etc.) to the first modified data record 208. The second update 210 is predicted based on any changes to the version of the shared data record accessed by client A202 to account for these changes to the underlying original shared data record. That is, the second update 210 is required as a result of applying the first update. Also, the application of the second update 210 is not requested by client A202 or another client (e.g., client B226, ..., client N228) among a plurality of clients. Instead, the rule application engine 110 determines whether the first modified data record 208 complies with the set of rules described above. If the first modified data record 208 does not comply with the set of rules described above, the rule application engine 110 generates the second update 210. Applying the second update 210 to the first modified data record 208 causes the first modified data record 208 to comply with the set of rules described above.

[0068] When the set of rules described above is applied to the first modified data record 208 (if appropriate), a second update 210 of the shared data record is generated according to the rules to correct any defects, errors, mistakes, etc. that may exist in the first modified data record 208 due to changes to the shared data record by client A202, and the shared data record is updated. When there are no changes to the first modified data record 208 as a result of applying the rules by the rule application engine 110, this second update 210 is not required. In this case, the rule application engine 110 does not change the first modified data record 208 and sends the first modified data record 208 to the client record comparison engine 114 instead of the second modified data record 214.

[0069] When the rule application engine 110 generates a second update, this second update 210 is applied to the first modified data record 208 to generate a second modified data record ("RDR2") 214.

[0070] Also, the rule application engine 110 may be configured to store the second update 210 in the data repository 118 for future reference. In a further approach, the rule application engine 110 can store the first modified data record 208 and / or the second modified data record 214 instead of or in addition to the second update 210.

[0071] If the client is requesting an update to the shared data record but not providing any changes, or if an event triggers an update to the shared data record (another client is requesting an update), the rule application engine 110 retrieves the latest version of the shared data record ("patch") 212 (or instructions on how to create the latest version, e.g., the second update 210) from the data repository 118 and is configured to provide the retrieved data record to the requesting client.

[0072] Also, the rule application engine 110 is configured to send the second modified data record 214 to the client record comparison engine 114. As described above, if the second update 210 is not required by the application of the rule, the rule application engine 110 sends the first modified data record 208 to the client record comparison engine 114.

[0073] In one or more embodiments, the client record comparison engine 114 is configured to determine the differences between two versions of the shared data record by comparing the second modified data record 214 with the version of the shared data record being accessed by client A 202. Once these differences are determined, a first response ("RESP1") 216 indicating these differences may be sent to client A 202 to conserve resources.

[0074] The client record comparison engine 114 can access the version of the shared data record being accessed by client A 202 from the client cache A cache 220. The client cache A cache 220 stores a copy resulting from a previous interaction with client A 202 when client A 202 requested access to the shared data record. An entry storing or indicating this version of the shared data record is created in the client A cache 220 for future reference.

[0075] In one embodiment, the client record comparison engine 114 can store in the client A cache 220 the differences between the second modified data record 214 and / or the determined second modified data record 214 and the version of the shared data record being accessed by client A 202 for future reference. In another approach, the first response 216 sent to client A 202 may include the second modified data record 214 instead of the differences between the determined second modified data record 214 and the version of the shared data record being accessed by client A 202. In this or any other approach, the client record comparison engine 114 can store the second modified data record 214 in the client A cache 220 for future reference.

[0076]

[0077] ​ When processing requests from other clients, such as client B226, the change integration engine 106 can retrieve the version of the shared data record accessed by client B226 from the request ("REQ") 232 sent by client B226, from the data repository 118, from the client B cache 222, and / or from the general ledger 120 in various ways. The request 232 may be a change request, an update request, or another type or form of message indicating that client B226 is accessing a shared data record that may not be up-to-date based on updates / changes made by other clients.

[0078] In one or more embodiments, the client record comparison engine 114 is configured to determine the differences between two versions of the shared data record by comparing the second modified data record 214 with the version of the shared data record accessed by client B206. Once these differences are determined, a first response ("RESP2") 218 indicating these differences may be sent to client B206 to conserve resources.

[0079] In response to a request 232 from client B226 for the latest shared data record, the client record comparison engine 114 can access, from the client B cache 222, the version of the shared data record being accessed by client B226. The client B cache 222 stores a copy resulting from a previous interaction with client B226, where client B226 requested access to the shared data record. An entry is created in the client B cache 222 to store or indicate this version of the shared data record for future reference. In one or more embodiments, the client record comparison engine 114 can store in the client B cache 222, for future reference, the second modified data record 214 and / or the difference between the determined second modified data record 214 and the version of the shared data record being accessed by client B226.

[0080] In another approach, the second response 218 sent to client B226 may include the second modified data record 214 instead of the difference between the determined second modified data record 214 and the version of the shared data record being accessed by client B226. In this or any other approach, the client record comparison engine 114 can store the second modified data record 214 in the client B cache 222 for future reference.

[0081] Figure 3 shows the functional blocks of a collaborative data record management system 300 according to one or more embodiments. A plurality of clients 304 are communicatively coupled to an event cache distribution module 306 that functions as a front end for the ledger service 302. The event cache distribution module 306 is configured to receive requests from the plurality of clients 304 and intelligently distribute the received requests to one or more ledgers 310 and a view state machine 308. Received requests are distributed intelligently to one or more ledgers 310 and a view state machine 308.

[0082] Each of the one or more ledgers 310 is configured to store unresolved update / change information for a single shared data record. This single shared data record is managed by a collaborative data record management system 300 and may be accessed and modified by at least one of a plurality of clients 304. In one approach, the unresolved update / change information stored in the various ledgers 310 includes changes and / or updates that have not yet been reflected in the particular version of the shared data record being viewed / accessed by one of the plurality of clients 304.

[0083] In one embodiment, the number of ledgers 310 may be approximately equal to the number of data records shared among the plurality of clients 304. In one or more embodiments, a ledger 310 may be created when an update / change to one of the shared data records is received, and may not exist prior to the collaborative data record management system 300 receiving and / or identifying these updates / changes. In another embodiment, a corresponding ledger may be created when the corresponding shared data record is formed (either by shared creation or instruction).

[0084] In one implementation, each ledger 310 can store a log of changes made to a particular shared data record by each particular client having access rights to the particular shared data record managed by the collaborative data record management server 300.

[0085] The view state machine 308 is configured to determine and maintain a portion and / or all of the records that a particular client 304 is permitted to view, access, and / or edit from one or more shared data records. In other words, the view state machine 308 receives information from one or more ledgers 310 and the event cache distribution module 306, and by reconciling the state of each shared data record that each client is currently accessing, ensures that access is granted to a particular client only when updates and changes are made to various shared data records.

[0086] The request-response distribution module 312 receives inputs from the ledger 310 and the view state machine 308 to determine the current state of all shared data records available to each of the various clients 304. Once this information is sorted, the request-response distribution module 312 transfers requests from multiple clients 304 and any useful and / or necessary information (the state or current version of the shared data record, access / editing rights of different clients, or updates / changes) to the service layer 314.

[0087] In the service layer 314, the information from the request-response distribution module 312 is received by the request routing module 316. The request routing module 316 is configured to determine where to send update / change requests from one of the multiple clients 304, for example, among various information. The request routing module 316 is configured to store data in the shared data cache 320 and the client-specific view state cache 318. The shared data cache 320 includes rules applied to various shared data records and other information useful for processing client requests. Each client-specific state cache 318 stores client-specific information that tracks and records view states of different data records, client access, and editing rights, etc.

[0088] 3. Cooperative Data Record Management of Shared Data Records In one embodiment, each client within a collaborative data record management system can access a specific data record that is shared by many clients of the collaborative data record management system. This specific shared data record may be managed by a data record management server that provides copies or instances of the specific shared data record to multiple clients simultaneously.

[0089] 3.1 Receiving Update / Change Requests In one embodiment, each client within a collaborative data record management system can request updates and / or changes to be applied to a specific shared data record.

[0090] In one approach, this request, called a change request, may be triggered by a change made to a specific shared data record on the device of one client. In another approach, this request may be triggered by a client opening and / or viewing a specific version of the shared data record that is not up-to-date. By this triggering action, the client sends what is called an update request for the specific shared data record. In either case, this request is received by the data record management server and can be used to determine the current state or version of the shared data record, including information that can be used regardless of the client that sent the request, and any updates / changes requested by the sending client.

[0091] For example, a user may delete a field in a table being viewed on a specific client. When the data record management server receives a notification that an out-of-date instance is being viewed / accessed on another client, it communicates the deletion of this field to all other instances of the table being viewed and / or accessed by other clients.

[0092] 3.2 Resolving Pending Changes When the data record management server receives a request, update, and / or change, it determines whether there are any pending updates / changes to a specific shared data record. These pending updates / changes may be submitted by one or more other clients. When a specific shared data record is being accessed simultaneously by multiple clients, differences may occur between the same version of the data record on multiple clients. These differences can become very large over time and can be very difficult to reconcile if propagated over a long period.

[0093] Accordingly, in one embodiment, each client that has a specific shared data record open sends an update request to reconcile any pending updates / changes made on other clients, even if no changes have been made to the specific shared data record on one client. When the data record management server receives the update request, it can send a response that includes the differences between the specific version of the shared data record being viewed / accessed by the client and the most recent version of the shared data record being managed by the data record management server.

[0094] In one or more embodiments, the data record management server can send periodic messages to all clients that are currently accessing or have previously accessed a specific shared data record. These periodic messages are unique to each client and indicate the differences between the specific version of the shared data record being viewed / accessed by each client and the most recent version of the shared data record being managed by the data record management server.

[0095] 3.3 Integration of Changes In one approach, the change integration engine can simplify pending updates and the updates and / or changes requested from requests before generating the integrated update. This simplification can include removing duplicate actions and / or operations, removing unresolved actions and / or operations resulting from the execution of another action and / or operation, generating an order for a plurality of operations required to perform an update on a shared data record, and rearranging the order of operations to reduce the processing amount and / or resource usage when performing the update, but is not limited thereto.

[0096] In one embodiment, the order of operations may be determined based on the time the change and / or update was received, such as FIFO, FILO, LIFO, etc. In another embodiment, the order of operations may be determined based on the resource usage required to perform each operation. For example, an operation that consumes the least resources may be executed before an operation that consumes more resources, or vice versa. In another approach, the order of operations may be determined based on a predetermined or implicit priority of the change and / or update.

[0097] The integrated update is generated by integrating all pending updates / changes and the changes indicated in the change request for a particular shared data record. By applying this generated integrated update to the particular version of the shared data record being accessed by the client that submitted the change request, all updates and changes indicated by this particular client and all other clients having edit rights to the particular shared data record can be applied.

[0098] 3.4 Application of Specific Rules to Shared Data Records After applying all requests and pending updates and / or changes to the shared data record, passing through the rule application engine ensures that the resulting record complies with specific rules. The rule application engine can determine issues within the shared data record by applying rules and generate updates that can be applied to the shared data record configured to overcome the detected issues.

[0099] The updates generated by the rule application engine are required to integrate the pending changes and requested changes and apply them to the shared data record. Also, the updates generated by the rule application engine cause changes to the shared data record that are not requested by any client but are specified by the rules themselves. Such changes may be independent of the changes made to the shared data record.

[0100] In one approach, the rules may be directed at determining the feasibility of the requested configuration, calculating prices, calculating inventory, configuring products, and / or determining quotes for configured products based on multiple price calculations.

[0101] These rules may be sorted into many different categories. Each category is directed at a specific characteristic of the data record. For example, some rule categories may include organization and format, configuration, pricing and cost, and user permissions and rights.

[0102] Organization and format rules can detect and correct issues resulting from changes the client may make to the data record that are considered undesirable. Some exemplary changes that may be made accidentally or inadvertently include duplicate entries, deletion of important content, entries with incorrect types or spellings, inconsistent formats, incorrect language including, but not limited to, words. These errors may be detected and corrected by applying rules for checking common compilation and formatting problems and applying known solutions to resolve such problems.

[0103] Configuration rules can detect and correct problems that arise when a shared data record is directed at the configuration of several articles, systems, devices, or products and a client makes changes to the data record that result in an incorrect, impossible, or generally unusable configuration. Some exemplary changes that can result in an unusable configuration include specifying an improper combination of components (e.g., specifying a bolt of the wrong size for a nut, specifying a cell phone battery for a desktop computer), specifying an inappropriate component for the overall system (specifying a battery that cannot drive a unit, specifying a fan that cannot move enough air to cool a processor), specifying incompatible components (e.g., specifying a metric bolt for a standard nut, using a DC fan on an AC power grid), but are not limited to these. These errors may be detected and corrected by applying rules for checking common configuration problems and applying known solutions to resolve such problems.

[0104] Price settings and cost rules can detect and correct problems resulting from a client making changes to data records, which causes component changes (thereby increasing or decreasing the cost of components in the assembled article, system, device, or product), changes in the number of components (thereby increasing or decreasing multiple cost factors), and / or changes in the number of assembled articles, systems, devices, or products. This is a typical configuration - price - estimate mechanism and logic. With this mechanism and logic, each client can make changes to the configuration to generate an estimate of the article, system, device, or product that can be produced at the estimated price, and then price settings and estimates are made based on available inventory, timing requirements, component location, etc.

[0105] User permission and rights rules can detect and correct problems resulting from unauthorized changes to data records based on factors such as the identity of the user making the change or system settings that do not permit certain changes. Some exemplary changes that can result in non - permission (e.g., the change is not permitted and the shared data record is reverted to the previous version) after applying the rules include a user without delete rights making a deletion, a user without administrative rights changing the format of a data record, and a client from the first department of an organization attempting to change a data record owned by the second department of the organization, but are not limited to these. These unauthorized changes may be detected and corrected by applying rules that check for common user permission and rights issues and applying known solutions to overcome such problems.

[0106] The rules applied to shared data records after applying all pending and requested changes are not limited to the categories described above, and depending on the architecture of the rule application engine, any kind of rule, algorithm, calculation, and operation that can be considered can be applied to the up - to - date data record.

[0107] 3.5 Relay of Updates to Specific Clients Accessing Shared Data Records While one client is accessing a specific shared data record, other clients can generate updates / changes to the specific shared data record. Also, by modifying the rules applied by the rule application engine, updates required for the specific shared data record can be generated.

[0108] In one embodiment, to maintain the consistency of a specific shared data record among all clients having access rights, periodic updates may be sent to each client actively accessing the specific shared data record. In another embodiment, periodic updates may be sent to all clients having access rights to a specific shared data record, regardless of their current activity with the specific shared data record. According to another embodiment, periodic updates of each shared data record managed by the data record management server may be sent to each client connected to the data record management server.

[0109] However, in order to minimize the usage of processing resources and transmission resources, in one embodiment, only the client that sent the update request or change request receives the information necessary to update the specific version of the shared data record accessed by a specific client at any given time. Since other clients have not sent requests, these clients are considered not to be using this specific shared data record. Also, when a specific shared data record is opened and / or accessed by any client, this action triggers sending an update request to the data record management server. Thereby, the specific shared data record is automatically updated.

[0110] 4. Exemplary Embodiments For the sake of clarity, detailed examples will be described below. The components and / or operations described below should be understood as specific examples that may not be applicable to a particular embodiment. Therefore, the components and / or operations described below should not be construed as limiting the scope of the claims.

[0111] 4.1 Providing Updates to Shared Data Records Based on Triggers FIG. 4 shows an exemplary method 400 for providing updates to a shared data record based on the detection of a trigger, according to one or more embodiments. One or more of the operations shown in FIG. 4 may be changed, rearranged, or omitted together. Therefore, the specific order of the operations shown in FIG. 4 should not be construed as limiting the scope of one or more embodiments.

[0112] In operation 402, one or more trigger events for updating the shared data record may be detected. In response to the detection of a trigger event, method 400 proceeds to operation 404. Otherwise, method 400 continues to wait for the detection of one trigger event at operation 402.

[0113] A trigger event corresponds to and / or is something that causes the shared data record to be updated. A trigger event can take any suitable form, detectable condition, state, and / or prompt for starting method 400. Some exemplary trigger events include the client requesting an update / change to the shared data record, the client accessing the shared data record, device startup, device stop and / or suspension / sleep, network change, requesting addition or removal of a device within a collaborative data record management system, the client receiving an update / change to the shared data record, opening a data record, storing a data record, including but not limited to these.

[0114] Detecting that a trigger event is satisfied may be performed by any device capable of performing such detection. Such a device may be one of the clients within a collaborative data record management system, a collaborative data record management ser ver, including, but not limited to, a common ledger.

[0115] In operation 404, upon detection of a trigger event, apply at least one update and / or change to the shared data record. In one approach, the update / change may be included in a change request received from one of the clients within the collaborative data record management system. Also, the update / change may be provided by one of the components of the collaborative data record management system and applied to the shared data record when one of the clients accesses the shared data record.

[0116] In one approach, the update / change to the shared data record may be obtained from a common ledger. The common ledger stores a log of updates made by each particular client of a plurality of clients to the version of the shared data record accessed by that particular client.

[0117] In one implementation, the update / change to the shared data record may be obtained from a client cache. The client cache stores a list of all updates made by the requesting client to the shared data record and an indicator indicating the current version of the shared data record accessed by the requesting client.

[0118] In operation 406, after applying the update / change, generate an update to the shared data record by applying rules specific to the collaborative data record management system to the shared data record. This rule-based update is requested and / or specified to apply the previous update / change requested by the client, but is not requested by any of the clients of the collaborative data record management system.

[0119] These rules may be directed to a particular type of data record and may be specific to previous updates / changes made to the shared data record by the requesting client. Depending on the architecture of the collaborative data record management system, any type of business procedure, compilation, format, pricing, cost analysis, inventory, calculation, algorithm, and / or operation may be included in the applied rules.

[0120] Also, there may be many different sets of rules. Among them, the first set of rules is applied to one type of data record (e.g., operation information log, sensor data, production and output records), and the second set of rules is applied to the second type of data record (e.g., word processing document, spreadsheet).

[0121] In operation 408, apply the rule-based update to the shared data record. If the application of the rule does not cause further updates to the shared data record, operation 408 does not apply the update.

[0122] In operation 410, send a message to at least one of the clients having access rights to the shared data record. This message includes the update, the latest data record, or both. The client can utilize the latest data record instead of any version previously used to keep the current view of the shared data record up to date.

[0123] If only the update is sent, the client can make the shared data record the latest with the latest changes resulting from the application of the rules by modifying the locally stored version of the shared data record using the update.

[0124] 4.2 Provision of Deltas for Updating Shared Data Records Based on Update Requests FIG. 5 shows an exemplary method 500 for providing differences of shared data records based on receiving requests from a client, according to one or more embodiments. One or more of the operations shown in FIG. 5 may be changed, rearranged, or omitted together. Accordingly, the specific order of the operations shown in FIG. 5 should not be construed as limiting the scope of one or more embodiments.

[0125] In operation 502, a request for updating a shared data record is received from a client within a shared data record management system. The client can request an update to the shared data record, request changes to be applied to the shared data record, or request access to the shared data record. This request indicates to the shared data record management system that the pending changes to this shared data record should be applied to the shared data record in order to update the version accessed by the requesting client.

[0126] In operation 504, it is determined whether there are any pending changes to the shared data record. Pending changes include updates and / or changes to the same shared data record requested by other clients and may be aggregated and simplified into a single update before being applied to the shared data record.

[0127] In operation 506, in response to receiving the request and determining that there are pending changes, the pending changes are applied to the shared data record. After generating an update based on the pending changes, this update is applied to the shared data record. However, this update may cause unwanted and / or unacceptable changes to the shared data record. Accordingly, according to one approach, in operation 508, by applying rules to the shared data record, it is determined whether all changes are appropriate and acceptable.

[0128] In one approach, pending changes to a shared data record may be retrieved from a common ledger. The common ledger stores a log of updates made by each particular client of a collaborative data record management system to the version of the shared data record accessed by that particular client.

[0129] In one embodiment, pending changes to a shared data record may be retrieved from a client cache. The client cache stores a list of all updates made by a requesting client to the shared data record and an indicator indicating the current version of the shared data record accessed by the requesting client.

[0130] In operation 508, after applying an update based on the pending changes, an update to the shared data record is generated by applying rules specific to the collaborative data record management system to the shared data record. This rule-based update is requested and / or specified to apply previous updates / changes requested by a client, but is not requested by any client of the collaborative data record management system.

[0131] These rules may be directed to a particular type of data record and may be specific to previous updates / changes made by the requesting client to the shared data record. Depending on the architecture of the collaborative data record management system, any type of business procedure, compilation, format, pricing, cost analysis, inventory, calculation, algorithm, and / or operation may be included in the applied rules.

[0132] Also, there may be many different sets of rules. Among them, the first set of rules is applied to one type of data record (e.g., operation information log, sensor data, production and output records), and the second set of rules is applied to a second type of data record (e.g., word processing document, spreadsheet).

[0133] In operation 510, apply the rule-based update to the shared data record. If applying the rule does not cause further updates to the shared data record, then in operation 510, do not apply the update.

[0134] In operation 512, determine the difference between the version of the shared data record being accessed by the requesting client and the most recent data record after applying the rule-based update. By determining these differences and storing the determined differences as the data records to be used to update the version of the shared data record being accessed by the requesting client, the processing power and communication resources can be saved when warning the requesting client of changes to the shared data record. In one approach, the differences may be sent to and stored in a common ledger.

[0135] In operation 514, send a message to the requesting client. This message includes the differences and / or the most recent data record, or both. This message may be sent to other clients in addition to the requesting client. When sending the most recent data record, the most recent data record may be sent to each client for updating the data record. When sending only the differences as the message, to maintain consistency among all clients within the shared data record management system and to make the shared data record the most recent with the most recent changes resulting from the application of the rules by modifying the locally stored version of the shared data record, these differences may be sent to any client accessing the same version of the shared data record as the requesting client.

[0136] The requesting client and any other client that receives the message can utilize the most recent data record instead of any version that was previously used to keep the current view of the shared data record up to date.

[0137] 4.3 Providing Deltas for Updating Shared Data Records Based on Change Requests FIG. 6 illustrates an exemplary method 600 for providing a delta to a shared data record based on receiving a change request from a client, according to one or more embodiments. One or more of the operations shown in FIG. 6 may be changed, rearranged, or omitted in their entirety. Accordingly, the specific order of the operations shown in FIG. 6 should not be construed as limiting the scope of one or more embodiments.

[0138] In operation 602, a change request for applying changes to a shared data record is received from a client within a collaborative data record management system. The client may request to apply changes to the shared data record based on an active operation being performed on the client or any other reason that may be detected by the client.

[0139] In operation 604, it is determined whether there are any outstanding changes to the shared data record. In response to there being outstanding changes, in operation 606, access is made to a common ledger to obtain the outstanding changes to the shared data record. In a further approach, the outstanding changes may be stored in a client cache specific to the requesting client and obtained from this source in addition to or instead of the common ledger.

[0140] Otherwise, method 600 proceeds to operation 608. In operation 608, the outstanding changes (if any) may be integrated with the changes requested by the request received in operation 602. Thereafter, the integrated changes can be simplified and / or applied in an intelligent manner to reduce resource consumption and ensure the consistency of changes applied from different sources (e.g., not modifying text within a section that has already been deleted). A modified data record can be generated according to all of the requested and outstanding changes by simplifying (if possible) and applying the outstanding changes to the shared data record.

[0141] The outstanding changes include updates and / or changes to the same shared data record requested by other clients, and can include other changes requested by the requesting client, corrections required for rule application, etc. The modified data record may include undesirable and / or unacceptable changes to the shared data record. Thus, in operation 610, by applying the rules to the shared data record, it is determined whether all changes are appropriate and acceptable.

[0142] In operation 610, a current data record is generated by applying rules specific to the collaborative data record management system to the modified data record. This rule-based update is requested and / or specified to apply previous updates / changes requested by the client, but is not requested by any client of the collaborative data record management system.

[0143] These rules may be directed to a particular type of data record and may be specific to previous updates / changes made to the shared data record by the requesting client. Depending on the architecture of the collaborative data record management system, any type of business procedure, organization, format, pricing, cost analysis, inventory, calculation, algorithm, and / or operation may be included in the applied rules.

[0144] Also, there may be many different sets of rules. Among them, the first set of rules is applied to one type of data record (e.g., operation information log, sensor data, production and output records), and the second set of rules is applied to the second type of data record (e.g., word processing document, spreadsheet).

[0145] If the application of the rules does not cause further updates to the modified data record, the modified data record after the application of the rules remains unchanged.

[0146] In operation 612, determine the difference between the version of the shared data record being accessed by the requesting client and the most recent data record after applying the rule-based updates. By determining these differences and storing the determined differences as the data records to be used to update the version of the shared data record being accessed by the requesting client, the processing capabilities and communication resources can be conserved when warning the requesting client of changes to the shared data record.

[0147] In one approach, the differences may be sent to and stored in a common ledger. In operation 614, send a message to the requesting client. This message includes the differences and / or the most recent data record, or both. This message may also be sent to other clients in addition to the requesting client. When sending the most recent data record, the most recent data record may be sent to each client for updating the data record. When sending only the differences as the message, to maintain consistency among all clients within the collaborative data record management system and modify the locally stored version of the shared data record so that the shared data record is up-to-date with the most recent changes resulting from the application of the rules, these differences may be sent to any client accessing the same version of the shared data record as the requesting client. The requesting client and any other client that receives the message can utilize the most recent data record instead of any version previously used to keep the current view of the shared data record up-to-date.

[0148]

[0149] 5. Computer Networks and Cloud Networks In one or more embodiments, a computer network provides connections between a set of nodes. These nodes may be local and / or remote from each other. These nodes are connected by a set of links. Examples of links include coaxial cables, unshielded twisted pair cables, copper cables, optical fibers, and virtual links.

[0150] One subset of nodes implements the computer network. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another subset of nodes uses the computer network. Such nodes (also called "hosts" or "clients") can execute client processes and / or server processes. A client process requests computing services (e.g., execution of a particular application and / or storage of a particular amount of data). A server process responds by executing the requested service and / or by returning the corresponding data.

[0151] The computer network may be a physical network that includes physical nodes connected by physical links. A physical node is any digital device. The physical node may be a hardware device with a specific function such as a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Additionally or alternatively, it may be a general-purpose machine configured to execute various virtual machines and / or applications that provide respective functions. A physical link is a physical medium that connects two or more physical nodes. Examples of links include coaxial cables, unshielded twisted pair cables, copper cables, and optical fibers.

[0152] The computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (such as a physical network). Each node in the overlay network corresponds to each node in the underlying network. Therefore, each node in the overlay network is associated with both an overlay address (for specifying the address of the overlay node) and an underlay address (for specifying the address of the underlay node that implements the overlay node). The overlay node may be a digital device and / or a software process (such as a virtual machine, an application instance, or a thread). The overlay nodes at both ends of the tunnel treat the underlying multi-hop path between the overlay nodes as a single logical link. Tunneling is performed by encapsulation and decapsulation.

[0153] In one embodiment, the client may be local and / or remote with respect to the computer network. The client can access the computer network via another computer network such as a private network or the Internet. The client can send requests to the computer network using a communication protocol such as the Hypertext Transfer Protocol (HTTP). The requests are sent via an interface such as a client interface (such as a web browser), a program interface, or an application programming interface (API).

[0154] In one embodiment, a computer network provides a connection between a client and network resources. The network resources include hardware and / or software configured to execute a server process. Examples of network resources include a processor, a data storage device, a virtual machine, a container, and / or a software application. The network resources are shared among a plurality of clients. The clients independently request computing services from the computer network. The network resources are dynamically allocated on demand to each request and / or each client. The network resources allocated to each request and / or each client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and / or (c) the aggregated computing services requested by the computer network. Such a computer network may be referred to as a "cloud network".

[0155] In one embodiment, a service provider provides a cloud network to one or more end users. Including but not limited to SaaS (Software-as-a-Service), PaaS (Platform-as-a-Service), IaaS (Infrastructure-as-a-Service). Various service models may be implemented by a cloud network. In SaaS, the service provider provides the end user with the ability to use the service provider's applications running on network resources. In PaaS, the service provider provides the end user with the ability to deploy custom applications on network resources. The custom applications may be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider provides the end user with the ability to provide processing, storage, network, and other basic computing resources provided by network resources. Any application, including an operating system, may be deployed on network resources.

[0156] In one embodiment, various deployment models including, but not limited to, private clouds, public clouds, and hybrid clouds may be implemented by a computer network. In a private cloud, network resources are provisioned to be exclusively used by a specific group consisting of one or more entities (the term "entity" as used herein refers to a company, organization, person, or other entity). The network resources may be local and / or remote to the premises of the specific group of entities. In a public cloud, cloud resources are provisioned to multiple entities (also referred to as "tenants" or "customers") that are independent of each other. The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a "multi-tenant computer network". Several tenants may be able to use the same specific network resources at different times and / or the same time. The network resources may be local and / or remote to the premises of the tenant. In a hybrid cloud, the computer network includes a private cloud and a public cloud. The interface between the private cloud and the public cloud enables data and application portability. Data stored in the private cloud and data stored in the public cloud may be exchanged via the interface. Applications implemented in the private cloud and applications implemented in the public cloud may have a dependency relationship with each other. Calls from applications on the private cloud to applications on the public cloud (and vice versa) may be executed via the interface. Applications implemented in the private cloud and applications implemented in the public cloud may have a dependency relationship with each other. Calls from applications on the private cloud to applications on the public cloud (and vice versa) may be executed via the interface.

[0157] In one embodiment, the tenants of a multi-tenant computer network are independent of each other. For example, the operations or business of one tenant may be separate from the operations or business of another tenant. Different tenants can request different network requirements from the computer network. Examples of network requirements include processing speed, data storage capacity, security requirements, performance requirements, throughput requirements, latency requirements, recovery requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to meet different network requirements requested by different tenants.

[0158] In one or more embodiments, tenant isolation in a multi-tenant computer network is achieved to ensure that the applications and / or data of different tenants are not shared with each other. Various tenant isolation techniques may be used.

[0159] In one embodiment, each tenant is associated with a tenant ID. Each network resource of the multi-tenant computer network is tagged with the tenant ID. A tenant is permitted to access a particular network resource only if the tenant and the particular network resource are associated with the same tenant ID.

[0160] In one embodiment, each tenant is associated with a tenant ID. Each application implemented by the computer network is tagged with the tenant ID. Additionally or alternatively, each data structure and / or dataset stored by the computer network is tagged with the tenant ID. A tenant is permitted to access a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID.

[0161] As an example, each database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a specific database. As another example, each entry in a database implemented by a multi-tenant computer network may be tagged with a tenant ID. Only the tenant associated with the corresponding tenant ID can access the data of a specific entry. However, the database may be shared by multiple tenants.

[0162] In one embodiment, the subscription list indicates the tenants having the right to access the application. A list of tenant IDs of the tenants having the right to access the application is stored for each application. Only when the tenant ID of a certain tenant is included in the subscription list corresponding to a specific application, is the tenant permitted to access that application.

[0163] In one embodiment, network resources corresponding to different tenants (e.g., digital devices, virtual machines, application instances, and threads) are separated into tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, any source within the tenant overlay network Packets from a device may be sent only to other devices within the same tenant overlay network. Encapsulation tunnels are used to prohibit any transmission from a source device on a tenant overlay network to a device within another tenant overlay network. Specifically, a packet received from a source device is encapsulated within an outer packet. The outer packet is sent from a first encapsulation tunnel endpoint (communicating with the source device on the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with the destination device on the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet in order to obtain the original packet sent by the source device. The original packet is sent from the second encapsulation tunnel endpoint to the destination device on the same specific overlay network.

[0164] 6. Others, extensions Embodiments relate to a system including a hardware processor and having one or more devices configured to perform any of the operations described herein and / or recited in any of the following claims.

[0165] In one embodiment, a non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, perform any of the operations described herein and / or recited in any of the claims.

[0166] Any combination of the features and functions described herein may be used in accordance with one or more embodiments. In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary according to implementation examples. Accordingly, the specification and the attached drawings are to be considered in an illustrative rather than a limiting sense. The sole and exclusive indicator of the scope of the invention and what the applicant intends the scope of the invention to be is the literal scope and equivalents of the claims obtained from this application in a particular form, including any subsequent amendments.

[0167] 7. Hardware Overview According to one embodiment, the techniques described herein are implemented by one or more dedicated computing devices (i.e., computing devices specially configured to perform a particular function). These dedicated computing devices may be hardwired to perform these techniques, or may include one or more application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or network processing units (NPUs) that are permanently programmed to perform these techniques, or may include one or more general purpose hardware processors programmed to execute these techniques according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such dedicated computing devices may also combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to perform these techniques. The dedicated computing device may be a desktop computer system, a portable computer system, a portable device, a networking device, or any other device incorporating hardwired logic and / or program logic to implement these techniques.

[0168] For example, FIG. 7 is a block diagram showing a computer system 700 in which an embodiment of the present invention can be implemented. The computer system 700 includes a bus 702 or other communication mechanism for communicating information, and a hardware processor 704 coupled to the bus 702 for processing information. The hardware processor 704 may be, for example, a general purpose microprocessor cessor.

[0169] In addition, computer system 700 includes main memory 706, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 702 for storing instructions and information to be executed by processor 704. Main memory 706 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor 704. When such instructions are stored on a non-transitory storage medium accessible to processor 704, computer system 700 is customized into a dedicated machine that executes the operations specified by the instructions.

[0170] Computer system 700 further includes read only memory (ROM) 708 or other static storage device coupled to bus 702 for storing static information and instructions for processor 704. A storage device 710, such as a magnetic disk or optical disk, is provided and coupled to bus 702 for storing information and instructions.

[0171] Computer system 700 may be coupled via bus 702 to a display 712, such as a cathode ray tube (CRT) monitor, for presenting information to a computer user. An input device 714 including alphanumeric keys and other keys is coupled to bus 702 for communicating information and command selections to processor 704. Another type of user input device is a cursor control 716 including a mouse, trackball, track pad, touch screen, or cursor direction keys, etc. for communicating direction information and command selections to processor 704 and controlling cursor movement on display 712. This input device typically has two degrees of freedom in two axes, for example, a first axis (e.g., x) and a second axis (e.g., y), and thus can specify a position within a plane.

[0172] Computer system 700 can implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, when combined with the computer system, makes or programs the computer system 900 into a dedicated machine. According to one embodiment, the techniques herein are performed by computer system 700 in response to one or more sequences of one or more instructions included in main memory 706 being executed by processor 704. Such instructions may be read into main memory 706 from another storage medium, such as storage device 710. Execution of the sequence of instructions included in main memory 706 causes processor 704 to perform the manual process steps described herein. In an alternative embodiment, hardwired circuitry may be used in place of or in combination with software instructions.

[0173] As used herein, the term "storage medium" refers to any non-transitory medium that stores data and / or instructions for operating a machine in a particular manner. Such storage media can include non-volatile media and / or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 710. Volatile media includes dynamic memory, such as main memory 706. Common forms of storage media include, for example, floppy (registered trademark) disks, flexible disks, hard disks, solid state drives, magnetic tape, or any other magnetic data storage medium, CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, RAM, PROM, EPROM, FLASH-EPROM, non-volatile random access memory (NVRAM), any other memory chip or cartridge, associative memory (CAM: content-addressable memory), and ternary associative memory (TCAM: ternary content-addressable memory).

[0174] A memory medium is different from a transmission medium but may be used in conjunction with the transmission medium. The transmission medium is involved in the transfer of information between memory media. For example, the transmission medium includes coaxial cables, copper wires, and optical fibers including the wires that make up bus 702. Also, the transmission medium may be acoustic or optical waves generated during radio wave communication and infrared data communication.

[0175] One or more sequences of one or more instructions can be carried to and executed by processor 704 using various forms of media. For example, the instructions may first be carried on the magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and transmit the instructions via a telephone line using a modem and send the instructions via the network. A NIC local to computer system 700 can receive data from the network and place the data on bus 702. Bus 702 carries the data to main memory 706. Processor 704 fetches and executes the instructions from main memory 706. The instructions carried to main memory 706 may optionally be stored in storage device 710 before or after being executed by processor 704.

[0176] Also, computer system 700 includes a communication interface 718 coupled to bus 702. Communication interface 718 provides a bi-directional data communication connection to network link 720 connected to local network 722. For example, communication interface 718 may be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem for providing a data communication connection to a corresponding type of telephone line. As another example, communication interface 718 may be a local area network (LAN) card for providing a data communication connection to a compatible LAN. A wireless link may be implemented. In such an implementation, communication interface 718 transmits and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0177] Network link 720 typically provides data communication to other data devices through one or more networks. For example, network link 720 can form a connection to data equipment operated by host computer 724 or Internet service provider (ISP) 726 via local network 722. ISP 726 provides data communication services via the worldwide packet data communication network commonly referred to as the "Internet" 728 today. Both local network 722 and Internet 728 use electrical, electromagnetic, or optical signals that carry digital data streams. Signals through various networks and signals on network link 720 through communication interface 718 are exemplary forms of transmission media that carry digital data between computer system 700.

[0178] Computer system 700 can send messages and receive data including program code via the network, network link 720, and communication interface 718. In the example of the Internet, server 730 can send the code of the requested application program via Internet 728, ISP 726, local network 722, and communication interface 718.

[0179] The received code may be executed by processor 704 upon receipt and / or stored in storage device 710 or other non-volatile storage device for later execution.

[0180] In the above specification, referring to many specific details that may vary by implementation example, the present invention The embodiments of the disclosure have been described. Therefore, the specification and the accompanying drawings should be considered in an illustrative sense rather than a limiting sense. The sole and exclusive indicator of the scope of the present invention, and the scope of the present invention intended by the applicant, is the literal scope and the equivalent scope of the claims obtained from this application in a specific form, including any subsequent amendments.

Claims

1. A non-transitory computer-readable medium including instructions that, when executed by one or more hardware processors, cause the following operations to be performed, wherein the operations include: receiving, from a first client, a change request including a first update to a shared data record, the shared data record being accessible by a plurality of clients including the first client; creating a first modified data record by applying at least the first update to the shared data record; applying one or more rules to the first modified data record to determine (a) a second update to the shared data record that is required to apply the first update but (b) is not requested by any of the plurality of clients; creating a second modified data record by applying the second update to the first modified data record; and transmitting the second modified data record to the first client.

2. Creating the first modified data record includes creating an integrated update by integrating the first update with any outstanding updates to the shared data record submitted by at least one other client among the plurality of clients, and creating the first modified data record by applying the integrated update to the shared data record. The medium according to claim 1.

3. The outstanding update to the shared data record is obtained from a common ledger, wherein the common ledger stores a log of updates made by each particular client of the plurality of clients to the version of the shared data record accessed by the particular client. The medium according to claim 2.

4. The outstanding update to the shared data record is obtained from a client cache, wherein the client cache stores a list of all updates made by the first client to the shared data record and an indicator indicating the current version of the shared data record accessed by the first client. The medium according to claim 2.

5. Applying the one or more rules includes operations selected from an operation group including determining the executability of the required configuration, calculating a price, calculating inventory, configuring a product, and determining a quote for the configured product based on multiple price calculations. The medium according to claim 1.

6. The operations are receiving, from a second client, an update request for the shared data record; determining a second set of differences between the second modified data record and a second version of the shared data record accessed by the second client; and further including transmitting the second set of differences to the second client. The medium according to claim 1.

7. The shared data record is accessed simultaneously by two or more of the plurality of clients, and each specific client of the plurality of clients has the right to edit the shared data record. The medium according to claim 1.

8. Creating the first modified data record includes applying a pending update requested by a second client among the plurality of clients. The medium according to claim 1.

9. The shared data record is accessed simultaneously by two or more of the plurality of clients, each specific client of the plurality of clients has the right to edit the shared data record, and creating the first modified data record includes creating an integrated update by integrating the first update and any outstanding updates to the shared data record submitted by at least one other client among the plurality of clients; and creating the first modified data record by applying the integrated update to the shared data record, wherein the outstanding updates to the shared data record are obtained from a common ledger or a client cache, and the common ledger stores a log of updates made by each specific client of the plurality of clients to the shared data record in the version accessed by the specific client. The client cache stores a list of all updates made to the shared data record by the first client and an indicator indicating the current version of the shared data record being accessed by the first client. Applying the one or more rules includes operations selected from an operation group including determining the executability of the requested configuration, calculating a price, calculating inventory, configuring a product, and determining a quote for the configured product based on multiple price calculations. The operations are receiving, from a second client, a second change request including a third update to the shared data record; creating a third modified data record by applying at least the third update to the shared data record; by applying the one or more rules to the third modified data record, determining a fourth update that is (a) required to apply at least the third update but (b) not required by any of the plurality of clients; determining a second set of differences between a second version of the shared data record being accessed by the second client and the fourth modified data record; further comprising sending the second set of differences to the second client. The medium according to claim 1.

10. A system comprising one or more hardware processors; a non-transitory computer-readable medium containing instructions that, when executed by the one or more hardware processors, cause the following operations to be performed: The operations are receiving, from a first client, an update request for a shared data record, the shared data record being accessible by a plurality of clients including the first client; creating a first modified data record by applying a pending change to the shared data record; by applying one or more rules to the first modified data record, determining a first set of one or more changes that are (a) required to apply at least the pending change but (b) not required by any of the plurality of clients; Creating a second modified data record by applying one or more changes of the first set to the first modified data record; Determining a set of differences between a first version of the shared data record accessed by the first client and the second modified data record; A system comprising transmitting the second modified data record to the first client. **Claim 11** The update request includes a change request from the first client, The system according to claim 10, wherein the change request includes a second set of one or more changes to the first version of the shared data record. **Claim 12** Creating the first modified data record comprises: Creating a set of integrated changes by integrating the second set of one or more changes and any outstanding changes to the shared data record submitted by at least one other client of the plurality of clients; The system according to claim 11, further comprising creating the first modified data record by applying the set of integrated changes to the shared data record. **Claim 13** The outstanding changes to the shared data record are obtained from a common ledger, The system according to claim 12, wherein the common ledger stores a log of changes made by the specific client to the version of the shared data record accessed by each specific client of the plurality of clients. **Claim 14** The outstanding changes to the shared data record are obtained from a client cache, The system according to claim 12, wherein the client cache stores a list of all changes made by the first client to the shared data record and an indicator indicating the current version of the shared data record accessed by the first client. **Claim 15** Applying the one or more rules includes actions selected from an action group consisting of determining the executability of a requested configuration, calculating a price, calculating inventory, configuring a product, and determining a quote for a configured product based on multiple price calculations. The system according to claim 10. **Claim 16** The actions are Receiving, from a second client, an update request for the shared data record; Determining a second set of differences between the second modified data record and a second version of the shared data record accessed by the second client; The system of claim 10, further comprising transmitting the second set of differences to the second client.

17. The shared data record is accessed simultaneously by two or more of the plurality of clients; The system of claim 10, wherein each particular client of the plurality of clients has an editing right with respect to the shared data record.

18. The operation is Receiving, from a second client, a request including a third update to the shared data record; Creating a third modified data record by applying at least the third update to the shared data record; By applying the one or more rules to the third modified data record, determining (a) a fourth update that is required to apply at least the third update but (b) is not requested by any of the plurality of clients; Determining a second set of differences between a second version of the shared data record accessed by the second client and the fourth modified data record; The system of claim 10, further comprising transmitting the second set of differences to the second client.

19. The system of claim 10, wherein creating the first modified data record includes applying a pending update requested by a second client among the plurality of clients.

20. A method comprising: Receiving, from a first client, a change request including a first update to a shared data record, the shared data record being accessible by a plurality of clients including the first client; Creating a first modified data record by applying at least the first update to the shared data record; By applying one or more rules to the first modified data record, (a) determining a second update of the shared data record that is required to apply the first update but (b) is not requested by any of the plurality of clients; Creating a second modified data record by applying the second update to the first modified data record; Including transmitting the second modified data record to the first client; The method is a method executed by at least one device including a hardware processor.

Images