Monotonic transactions in multi-master database with loosely coupled nodes

The present invention relates to databases, especially monotonous transactions in a multi-master database.

Online Transaction Processing (OLTP) applications are used for databases that provide ACID (High Atomicity, Consistency, Independence and Persistence) consistency characteristics, but loosely coupled "APs" with less consistent guarantees. (Availability, partition tolerance) settings are working more and more. In particular, when a transaction inserts a row and commits, the application expects one of three responses: a) transaction success, b) transaction rolls back (eg, constraint violation), c) transaction. Unknown status (usually due to a driver or connection error, and the application can issue a query to check the status). However, in either case, after a commit, subsequent reads in a traditional ACID database management system (DBMS) will encounter the same answer a (ie, monotonous behavior). If one query encounters an inserted row, subsequent queries will also encounter those inserted rows, and consistently (for response c) the app will issue a read to check the situation. I have to find out.

In an AP environment (for example, with many NoSQL (Unstructured Query Language) DBMSs), there is a fourth response regarding the problematic response state: d) The transaction status may not yet be finalized. This is because the node executing the transaction (where the node is a client device, server or peer device) sent a change / insert (as a log message) to another replica, but affirmations from them. Occurs when you have not heard a response (indicating that they have received or accepted the change). In this state, subsequent queries will encounter unpredictable behavior. The first query may not find those rows--because they have not yet replicated to a sufficient number of replicas (according to the quorum policy). However, later queries may find those rows.

<p> Therefore, the problem to be solved by the invention is to provide methods, computer programs, and devices for monotonous transactions in a multi-master database with loosely coupled nodes.</p>

<p> The embodiment relates to quorum processing for replication in a multi-master database by loosely coupled nodes. One embodiment is a method for monotonous transactions in a multi-master database with loosely coupled nodes, where the client device issues a write transaction on one of the nodes and locally on the node issuing the write transaction. Includes recording a write transaction in and asynchronously replicating a write transaction to at least one other node, and waiting for a positive response from at least the quorum of the node before returning a response to the client device. Provides a method, including performing a write transaction protocol by a processor. Quorum is any set of nodes, including a special node and at least one other node.</p><p> These and other features, embodiments and advantages of the present invention will be understood with reference to the following description, the accompanying claims and the accompanying figures.</p><p> Embodiments of the present invention will be described herein merely as an example with reference to the accompanying drawings.</p>

<figref num="1">It is a figure which draws the cloud computing environment by embodiment.</figref><figref num="2">It is a figure which draws a set of abstraction model layers by an embodiment.</figref><figref num="3">An embodiment is a network architecture for efficient representation, access and modification of variable length data objects.</figref><figref num="4">FIG. 5 illustrates a representative hardware environment that can be associated with the server and / or client of FIG. 1 according to an embodiment.</figref><figref num="5">FIG. 6 is a block diagram illustrating a system of quorum processing for replication in a multi-master database with loosely coupled nodes according to one embodiment.</figref><figref num="6">FIG. 6 is a block diagram for a process for monotonous transactions in a multi-master database with loosely coupled nodes, according to one embodiment.</figref>

Descriptions of the various embodiments have been presented for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many changes and variations will be apparent to those of skill in the art without departing from the scope and ideas of the embodiments described. The technical terms used herein best describe the principles of the embodiment, practical applications or technical improvements to the techniques found on the market, or the embodiments disclosed herein by one of ordinary skill in the art. Selected to be able to understand.

Although this disclosure includes a detailed description of cloud computing, it is understood in advance that the implementation of the teachings detailed herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment currently known or developed in the future.

One or more embodiments provide quorum processing for replication in a multi-master database by loosely coupled nodes. One embodiment is a method for monotonous transactions in a multi-master database with loosely coupled nodes, where the client device issues a write transaction on one of the nodes and locally on the node issuing the write transaction. Includes recording a write transaction in and asynchronously replicating a write transaction to at least one other node, and waiting for a positive response from at least the quorum of the node before returning a response to the client device. Provides a method, including performing a write transaction protocol by a processor. Quorum is any set of nodes, including a special node and at least one other node.

Cloud computing is a configurable computing resource (eg, network, network bandwidth, server, processing, memory) that can be quickly provisioned and released with minimal administrative effort or interaction with service providers. , Storage, applications, virtual machines (VMs) and services) is a model of service distribution to enable convenient and on-demand network access to shared pools. This cloud model may include at least 5 characteristics, at least 3 service models and at least 4 deployment models.

The characteristics are as follows: On-demand self-service: Cloud consumers automatically add computing capabilities such as server time and network storage as needed, without the need for human interaction with the service provider. Can be provisioned as a target. Wide Area Network Access: Features are available through the network and are accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg mobile phones, laptops and PDAs). Resource pooling: Provider's computing resources are pooled to provide multiple consumers with different physical and virtual resources that are dynamically allocated and reassigned according to demand using a multi-tenant model. .. Consumers generally do not have control or knowledge of the exact location of the resources provided, but may be able to locate at a higher level of abstraction (eg, country, state or data center). , There is a sense of position independence. Rapid Elasticity: Functions can be provisioned and scaled out rapidly, quickly released and scaled in rapidly, optionally automatically. To consumers, the features available for provisioning often appear to be endless and can be purchased in any quantity at any time. Measurement Services: Cloud systems automatically control and control resource usage by leveraging measurement capabilities at certain levels of abstraction appropriate for the type of service (eg storage, processing, bandwidth and active consumer accounts). Optimize. Resource usage is monitored, controlled and reported, thereby providing transparency to both providers and consumers of the services used.

The service model is as follows: Software as a Service (SaaS): The functionality provided to consumers is the ability to use the provider's applications running on the cloud infrastructure. Applications are accessible from a variety of client devices through thin client interfaces such as web browsers (eg, web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage or even individual application features, except in some cases with limited consumer-specific application configuration settings. Platform as a Service (PaaS): The functionality provided to consumers is the ability to deploy consumer-created or captured applications created using the programming languages and tools supported by the provider onto the cloud infrastructure. Is. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems or storage, but have control over deployed applications and possibly application hosting environment configurations. Infrastructure as a Service (IaaS): The functionality provided to consumers allows processing, storage, networks, and any software that consumers can deploy and run, including operating systems and applications. , The ability to provision other basic computing resources. Consumers do not manage or control the underlying cloud infrastructure, but are limited to operating systems, storage, control over deployed applications, and possibly selected networking components (eg, host firewalls). Has control.

The deployment model is: Private cloud: The cloud infrastructure operates exclusively for the organization. It may be controlled by the same organization or a third party, and may be on or off the premises. Community Cloud: The cloud infrastructure is shared by several organizations and supports specific communities with shared matters (eg, missions, security requirements, policies and compliance issues). It may be controlled by the same organization or a third party, and may be on or off the premises. Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services. Hybrid cloud: The cloud infrastructure remains a unique entity, but with standardized or proprietary technologies that enable data and application portability (eg, cloud bursting for load balancing between clouds). A combination of two or more clouds (private, community or public) that are combined.

Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity and semantic interoperability. At the heart of cloud computing is an infrastructure with a network of interconnected nodes.

With reference to Figure 1, an exemplary cloud computing environment 50 is depicted. As illustrated, the cloud computing environment 50 is a cloud, such as a mobile information terminal (PDA) or cellular phone 54A, desktop computer 54B, laptop computer 54C or automotive computer system 54N or a combination thereof. It comprises one or more cloud computing nodes 10 with which local computing devices used by consumers may communicate. Node 10 may communicate with each other. They may be physically or virtually grouped into one or more networks, such as the private, community, public or hybrid clouds or combinations thereof described herein above (not shown). This allows the cloud computing environment 50 to provide the infrastructure, platform or software or a combination thereof as a service that cloud consumers do not need to maintain resources on their local computing devices. .. The types of computing devices 54A-N illustrated in Figure 2 are intended to be merely exemplary, and the computing node 10 and cloud computing environment 50 are of any type of network or network address. It is understood that it is possible to communicate with any kind of computerized device through possible connections (eg, using a web browser) or both.

Referring now to FIG. 2, a set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 1) is illustrated. It should be understood in advance that the parts, layers and functions illustrated in FIG. 2 are intended to be merely exemplary and that embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding features are provided:

Hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframe 61; RISC (reduced instruction set computer) architecture-based server 62; server 63; blade server 64; storage device 65; as well as network and networking component 66. In some embodiments, software components include network application server software 67 and database software 68.

Virtualization layer 70 provides an abstraction layer in which the virtual entities in the following examples can be provided: virtual server 71; virtual storage 72; virtual network including virtual private network 73; virtual application and operating system. System 74; as well as virtual client 75.

In one example, management layer 80 may provide the following functions. Resource provisioning 81 provides the dynamic procurement of computing resources and other resources used to perform tasks within a cloud computing environment. Measurement and pricing 82 provides cost tracking when resources are used within a cloud computing environment, and billing or billing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides protection for data and other resources, as well as identity verification for cloud consumers and tasks. User Portal 83 provides consumers and system administrators with access to the cloud computing environment. Service Level Management 84 provides cloud computing resource allocation and management to meet the required service levels. Service Level Agreements (SLA) Planning and Execution 85 provides pre-arrangement and procurement of cloud computing resources that are expected to be required in the future in accordance with the SLA.

Workload tier 90 provides an example of functionality in which a cloud computing environment can be leveraged. Examples of workloads and features that can be provided from this layer are: Mapping and Navigation 91; Software Development and Lifecycle Management 92; Virtual Classroom Education Delivery 93; Data Analysis Processing 94; Transaction Processing 95; and Loosely Connected Nodes Quorum processing for replication in a multi-master database by 96. As mentioned above, all of the above examples described with respect to FIG. 2 are merely exemplary, and the invention is not limited to these examples.

All functions of one or more embodiments described herein can be tangibly embodied as a processing system 300 (FIG. 3) or as a hardware processor and with modules of program code. It is understood that this may be typically done by an autonomous cloud environment 410 (Figure 4). However, this does not have to be the case for non-real time processing. Rather, with respect to non-real time processing, the functionality detailed herein may be implemented / implemented or enabled by any of layers 60, 70, 80 and 90 illustrated in FIG. Or both can be.

Although the disclosure includes a detailed description of cloud computing, it is repeated that the implementation of the teachings detailed herein is not limited to cloud computing environments. Rather, embodiments of the invention may be implemented with any type of clustered computing environment currently known or developed in the future.

FIG. 3 illustrates a network architecture 300 according to one embodiment. As illustrated in FIG. 3, a plurality of remote networks 302 are provided, including a first remote network 304 and a second remote network 306. The gateway 301 may be coupled between the remote network 302 and the proximity network 308. In the context of the Network Architecture 300, networks 304 and 306 may take any form including, but not limited to, LANs, WANs such as the Internet, public switched telephone networks (PSTNs), private telephone networks, etc., respectively.

In use, the gateway 301 acts as an entry point from the remote network 302 to the proximity network 308. Therefore, the gateway 301 may function as a router capable of guiding a packet of given data arriving at the gateway 301, and as a switch providing the actual route to and from the gateway 301 for a given packet. good.

Further included is at least one data server 314 coupled to the proximity network 308, which is accessible from the remote network 302 via the gateway 301. It should be noted that the data server 314 may contain any kind of computing device / groupware. Multiple user devices 316 are associated with each data server 314. Such user device 316 may include desktop computers, laptop computers, handheld computers, printers or any other type of logic containing device or a combination thereof. It should be noted that in some embodiments, the user device 311 may also be directly coupled to any of the networks.

Peripheral device 320 or a set of peripheral devices 320, such as facsimile machines, printers, scanners, hard disk drives, network and / or local storage units or systems, may be one or more of networks 304, 306, 308. May be combined with. It should be noted that the database and / or additional components may be used with or incorporated into any kind of network element coupled to networks 304, 306, 308. In the context of this description, a network element may refer to any component of the network.

According to some techniques, the methods and systems described herein are virtual systems or MICROSOFT (R) WINDOWS, UNIX (R) systems that emulate an IBM (R) z / OS (R) environment. One or more, such as a UNIX (R) system that virtually hosts an (R) environment, a MICROSOFT (R) WINDOWS (R) system that emulates an IBM (R) z / OS (R) environment, etc. It may be implemented with, or both of, and / or a system that emulates a system of. This virtualization and / or emulation may be implemented through the use of VMWARE (R) software in some embodiments.

FIG. 4 illustrates a typical hardware system 400 environment associated with user device 316 and / or server 314 of FIG. 3, according to one embodiment. In one example, the hardware configuration includes a central processing unit 410 such as a microprocessor, and a workstation with several other units interconnected via the system bus 412. The workstation illustrated in Figure 4 is an I / O for connecting peripheral devices such as random access memory (RAM) 414, read-only memory (ROM) 416, and disk storage unit 420 to bus 412. Connect other user interface devices, such as O-adapter 418, keyboard 424, mouse 426, speaker 428, microphone 432, or touch screen, digital camera (not shown), or a combination thereof to bus 412. Includes a user interface adapter 422 for connecting a workstation to a communication network 435 (eg, a data processing network), a communication adapter 434 for connecting a bus 412 to a display device 438, and a display adapter 436 for connecting a bus 412 to a display device 438. good.

In one example, the workstation may have an operating system such as MICROSOFT (R) WINDOWS (R) operating system (OS), MAC (R) OS, UNIX (R) OS, etc. resident on it. In one embodiment, the system 400 utilizes a POSIX (R) based file system. It will be appreciated that other examples may be implemented on platforms and operating systems other than those mentioned. Other such examples may include operating systems written using the JAVA (R), XML, C or C ++ language or combinations thereof, or other programming languages, along with object-oriented programming methodologies. Object-oriented programming (OOP), which is becoming more and more used to develop complex applications, may also be used.

In a traditional duplicate database, the data object has copies that reside in multiple locations. A crucial consistency guarantee that such a database gives to an application is monotonous reading. A write operation (formerly also known as a transaction) atomically changes the database state, and all subsequent reads (queries) encounter the change in operation (in this case, the operation is said to be successful or committed). Either the operation is not encountered (in this case, the operation is said to have rolled back). In traditional replication databases, this guarantee is achieved through a quorum-based replica control protocol with synchronous blocking writes. Specifically, each copy of the duplicate data item is assigned a vote. Each operation then reads or writes a data item, respectively, with a read quorum (T)._r) Or write quorum (T)_w) Must be obtained. If a given data item has a total T-vote, the quorum must obey the following rules: 1. T_r+ T_w&gt; T 2.T_w&gt; T / 2

A write operation must wait for changes from its write to replicate to a replica of the write quorum, which must be validated by waiting for an acknowledgment. In addition, if this wait process fails or times out, the write must be rolled back. This is typically achieved with a two-phase commit protocol. Therefore, these rules ensure that the two write quorums always have a common node, and that any read quorum contains at least one site with the latest version of the data item. Therefore, whether the write is atomically successful or rolled back, all subsequent reads encounter a consistent image of the database. In such a consistent system, there could also be a third response phase: write operation status unknown. This can happen, for example, when the connection between the database and the application fails, or when the application times out while waiting for a response from the database. But still, even in such a situation, the application can query the database for the status of the write operation-and that query (all subsequent queries) will encounter a consistent answer. The disadvantage of this approach is that it requires a tightly connected system in which the node is available and responsive. For example, once the two-phase commit protocol has started, once the initiator node becomes unresponsive, the system is unavailable for subsequent reads.

Indistinguishable from a consistent system with three response phases (ie success, failure rollback and unknown), eventually consistent systems allow the application to eventually get a monotonous read, but slightly after the write is complete. You may have time to read inconsistent answers at this time. If the database state is changed by a write operation, the response status is successful and unknown. In the last case, subsequent reads will give different answers. If the read goes to one of the nodes where the change is duplicated, the read may encounter the change, the later read (going to a different node) may not encounter the change; then another read encounters the change. However, eventual consistency systems are highly available. Writes can occur on any node ("multi-master"); asynchronously replicated to other nodes; and the system can tolerate the failure of several nodes.

Multi-master replication (or peer-to-peer n-way replication) is a database replication in which data is stored by a group of computers and updated by any member of the group. Is the method. Updates made to individual master sites are propagated to all other master sites. Multi-master replication provides data convergence for all database table replicas, while providing global transactional consistency and data integrity. Conflict resolution is handled independently on each master node. Multi-master replication provides a complete replica of each replica database table on each master node. All members respond to client data queries. The multi-master replication system serves to propagate the data changes made by each member to the rest of the group and resolve any conflicts that may occur between parallel changes made by different members. Multi-master replication provides increased availability and faster server response times.

Traditional ACID In the DBMS, four states of atomicity, consistency, independence and persistence provide: With respect to atomicity, database modification transactions (ie, atomic transactions) must obey the "all or nothing" rule. If part of the transaction fails, the entire transaction fails. For consistency, only valid data will be written to the database. If a transaction that violates the database consistency rules is executed, the entire transaction will be rolled back and the database will be restored to a state consistent with those rules. If the transaction runs and succeeds, it moves the database from one state that is consistent with the rules to another that is also consistent with the rules. With respect to independence, multiple transactions that occur at the same time do not affect each other's execution. For two simultaneous issued transactions to the database, both transactions act on the database in an independent manner. The database performs the entire transaction and then the others, or vice versa. This prevents one transaction from reading intermediate data that is generated as a side effect of some of the other transactions that would not eventually be committed to the database. The independence property does not guarantee which transaction will be executed first, but that they do not interfere with each other. With regard to persistence, any transaction committed to the database will not be lost. Persistence uses backups and transaction logs that facilitate the restoration of committed transactions regardless of subsequent failures (eg, software or hardware failures).

FIG. 5 is a block diagram illustrating a system 500 of quorum processing for replication in a multi-master database with loosely coupled nodes according to one embodiment. In one embodiment, the system 500 includes a client device 510 (eg, a mobile device, a smart device, a computing system, etc.), a cloud or resource sharing environment 520, and a server 530. In one embodiment, the client device is provided with cloud services from server 530 through the cloud or resource sharing environment 520. In one embodiment, the system 500 is a multi-master database system that uses a consensus protocol to specify that one node is elected as a special node (or reader node). Consensus is the process of agreeing on one outcome within a group of participants. In one embodiment, in System 500, with respect to the write quorum, a special node and at least one non-special (or non-reader) node must be part of any write quorum. With respect to the read quorum, a special node and at least one non-special node must be part of any read quorum. Note that both write and read quorums may require additional nodes to be participants, depending on their persistence requirements. After a commit transaction, the initiator node waits for the log of that transaction to be replicated (and received an acknowledgment) to the node in the write quorum before returning a SUCCESS result notification. The initiator node never times out while waiting for an ack. The application may time out, in which case the response state is transaction status UNKNOWN (unknown).

In one embodiment, in system 500, writes (transactions) can go to any node. In one embodiment, the system 500 employs a quorum read quorum write protocol in which the read encounters only the data visible at the quorum nodes and the quorum is one or more pairs of nodes. In one embodiment, the quorum is any set with at least most of the nodes. System 500 maintains a special node chosen and uses the write protocol and write quorum, where: write is notified to them by at least the node with the write quorum (that the write was duplicated). Wait until, the write operation never times out, and any read quorum and any write quorum always contains a special node and at least one other node.

It should be noted that in one or more embodiments, a particular node may fail at any time and a new special node may have to be elected. For this reason, special quorum does not work. When a new special node is elected, which successful transaction (commit returns SUCCESS, it returns state, transaction status UNKNOWN), and subsequent queries encounter transaction changes. In that case, the transaction is successful) is also guaranteed to have their respective changes propagated to at least one other node in addition to the previous special node. Other nodes may be used to restore all successful transactions, even if the previous special node is currently unresponsive.

In one embodiment, in system 500, the write protocol is such that the system 500 1) issues a write on any node; 2) records the write locally (on that node) and asynchronously replicates to the other node. 3) Wait until an acknowledgment of receipt is received at least from the node of the quorum; 4) If the client device 510 can time out during 3), find out the write status by issuing a read. May include.

In one embodiment, in System 500, the read protocol is such that System 500 may: 1) issue a read on any node; 2) the read is known to be replicated by at least a quorum node. Returns only the line that is there; 3) If the read in 2) timed out because the special node did not respond, the system 500 would choose a new special node via the consensus protocol, and then to 2). Including that to follow.

In one embodiment, system 500: 1) issues a write on node A (chosen as a special node), where system 500 has other nodes B, C, D and E; 2) client. Device 510 times out and issues a read on one of the nodes, eg node C. In this example, on system 500, the read returns only the rows visible on A and one other node. If node C receives a write in 1), the read encounters the same write. Otherwise, node C waits to receive notifications from node A, B, D or node E or a combination thereof. If node C is notified that node A and at least one of nodes B, C, D, and E have received a write, the read encounters the write. If the process waits for node A and times out, and none of nodes B, C, D, and E have yet received a write, a new special node is elected. The original write is lost. Otherwise, the write will always appear to this read and subsequent reads.

In one embodiment, the system 500 may implement a weighted system as follows. Suppose you have three nodes. Special nodes may have a weight of 0.9. The other two nodes each have a weight of 0.3. In one embodiment, the threshold for quorum is that the sum of the weights must be 1.2, which is one other node in addition to the special node. It should be noted that other weighted systems may be used accordingly.

One or more embodiments provide the following advantages: Transactions can commit even in a loosely coupled environment where the network may be disrupted or the node may fail; only the reader node. Instead, a transaction can be submitted to any node; even when the transaction's response status is unknown, the application still has a monotonous read. Since the read quorum contains special nodes, it is never possible for one read to miss the inserted row and subsequent reads to find them.

FIG. 6 illustrates a block diagram for process 600 for monotonous transactions in a multi-master database with loosely coupled nodes, according to one embodiment. At block 610, process 600 performs a write transaction protocol by a processor (eg, the processor in cloud computing environment 50, Figure 1, System 300, Figure 3, System 400, Figure 4, System 500, Figure 5). .. At block 620, process 600 continues: the client device is one of the nodes (eg, client device 510, server 530, or any other peer in cloud computing environment 50, system 300, system 400 or system 500). · Issuing a write transaction on the device), recording the write transaction (change) locally on the node issuing the write transaction, and asynchronously replicating the write transaction to at least one other node, and the client. Performs a write transaction protocol that includes waiting for a positive response from at least the node's quorum before returning a response to the device. In one embodiment, a quorum is any set of nodes, including a special node and at least one other node (and optionally another node).

Process 600: Issuing a read transaction on one of the nodes, attempting to return a row known to be duplicated by at least the quorum of the node, and the special node being unresponsive. Against the time-out of trying to return a row that is known to be duplicated by at least the quorum of the node based on: selecting a new special node and being duplicated by at least the quorum of the node It may further include doing a read transaction protocol by the processor, including repeating attempts to return a line known to be present.

In one embodiment, process 600 further determines that the client device has timed out while waiting to receive an acknowledgment from the multi-master database, and then the client device has at least one read transaction. Get the status of the write transaction by issuing. The client device then waits for a response to this read transaction; and after this wait exceeds the timeout threshold, the client device retries the read transaction repeatedly. In one embodiment, in process 600, the selection of special nodes involves elections.

In one embodiment, process 600 comprises a special node being one of the nodes and elections being conducted by a processor using a consensus protocol. In one embodiment, process 600 determines that at least one read transaction has timed out, and then the client device repeats at least one read transaction.

In one embodiment, for process 600, the selection of a new special node is made by the processor due to a transaction failure or the non-reaction of the special node.

In one embodiment, process 600 may further include some other node where the quorum is selected based on the persistence requirement. Process 600 may further include assigning weights to nodes that include special nodes. For process 600, the weight assigned to a particular node may exceed the weight assigned to the remaining nodes, and the quorum vote may be based on the sum of the voting node weights that are greater than or equal to the quorum threshold.

Any combination of one or more computer-readable storage media may be utilized. The computer-readable storage medium may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or devices, or any suitable combination described above, but is not limited thereto. More specific examples (non-exhaustive enumeration) of computer-readable storage media can include: electrical connections with one or more wires, portable computer diskettes, hard disks, random access. -Memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), fiber optics, portable compact disk read-only memory (CD-ROM) ), Optical storage device, magnetic storage device, or any suitable combination of the above. In the context of this document, the computer-readable storage medium may be any tangible medium that may contain or store programs for use by, or related to, instruction execution systems, devices or devices.

The computer-readable signal medium may include a propagated data signal in which the computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such propagating signals may take any of various forms including, but not limited to, electromagnetic, optical or any suitable combination thereof. The computer-readable signal medium is not a computer-readable storage medium and may be any computer-readable medium capable of communicating, propagating or transferring a program for use by or related to an instruction execution system, device or device. good.

The program code embodied in a computer-readable medium uses any suitable medium, including, but not limited to, wireless, wireline, fiber optic cable, RF, etc., or any suitable combination described above. May be transmitted.

Computer program code for performing operations for aspects of the invention can be object-oriented programming languages such as Java (R), Smalltalk (R), C ++, and "C" programming languages or similar programming languages. It may be written in any combination of one or more programming languages, including traditional procedural programming languages. The program code is entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on the remote computer, or It may run entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or to an external computer. A connection may be made (eg, over the Internet using an Internet service provider).

Aspects of the present invention are described below with reference to the flow chart examples and / or block diagrams of the methods, devices (systems) and computer program products according to embodiments of the present invention. It will be appreciated that each block of the flowchart example and / or block diagram, and the combination of blocks in the flowchart example and / or block diagram, can be implemented by computer program instructions. These computer program instructions are functions / actions in which an instruction executed through the processor of a computer or other programmable data processing device is specified in one or more blocks of a flowchart, a block diagram, or both. It may be provided to the processor of a general purpose computer, a dedicated computer or other programmable data processing device to generate a machine so as to give rise to a means for implementation.

These computer program instructions also produce a product in which the instructions stored on a computer-readable medium contain instructions that implement a function / action identified in one or more blocks of a flowchart and / or block diagram. As such, it may be stored on a computer-readable medium and can be instructed to function in a particular manner to a computer, other programmable data processor or other device.

Computer program instructions also provide a process for an instruction executed on a computer or other programmable device to implement a function / action identified in one or more blocks of flowcharts and / or block diagrams. As such, it is loaded into a computer, other programmable data processor or other device to spawn a computer implementation process, causing a series of operational steps to be performed on the computer, other programmable device or other device. You may.

The flowcharts and block diagrams in the diagrams illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment or part of an instruction, which comprises one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figure. For example, two blocks illustrated in succession may actually be executed substantially in parallel, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. Each block of the block diagram and / or flow chart example, and the combination of blocks in the block diagram or flowchart example or both, performs the specified function or action or the dedicated hardware and computer instruction combination. It will also be noted that it can be implemented by the base system.

Claims to a singular element are intended to mean "one or more" rather than "one and only" unless explicitly stated. It is intended by this claim to include all structural and functional equivalents of the elements of the above exemplary embodiments known to those of skill in the art now or will become known in the future. The claimed elements of this application shall not be construed under Article 112, paragraph 6 of the U.S. Patent Act unless the elements are explicitly detailed using the phrase "means for" or "steps for". ..

The technical terms used herein are solely for the purpose of describing particular embodiments and are not intended to limit the invention. As used herein, the singular forms "a", "an" and "the" are plural unless the context explicitly states. Also intended to include. The terms "comprises" and / or "comprising", as used herein, identify the existence of a stated feature, perfection, step, action, element or part or combination thereof. However, it will be further understood that it does not preclude the existence or addition of one or more other features, perfections, steps, actions, elements, parts or groups thereof or combinations thereof.

Corresponding structures, materials, acts and equivalents of all means or step plus function elements in the attached claims are any structure for functioning in combination with other claims in detail. , Materials or acts are intended to be included. The description of the invention is presented for purposes of illustration and illustration, but is not intended to be exhaustive or limited to the disclosed form of the invention. Many changes and variations will be apparent to those skilled in the art without departing from the scope and ideas of the invention. Embodiments are intended to best illustrate the principles, practical applications of the invention, and allow one of ordinary skill in the art to understand the invention with respect to various embodiments with various modifications suitable for the particular intended use. Selected and explained to be.