Method and system for an electronic document framework

Methods and systems providing for the generation, sending, updating, and monitoring of electronic documents (eDocuments) based on source documents created in Enterprise Resource Planning (ERP) software. An eDocument is generated based on existing source documents, external data, or from other eDocuments. The method and systems ensure that the generated eDocument is compliant with any technical requirements. The eDocument is generated using a document process which transforms a non-compliant source document into a compliant eDocument. An eDocument Framework system can include a mapping application, application interface framework (AIF), an eDocument interface, and a process manager. The AIF is configured to interact with a cloud services provider to create a highly automated process of generating, sending, updating, and monitoring the eDocuments. The cloud service provider is also configured to interact with local authorities. The eDocument Framework system can also include a partner connector to interface with a business partner.

RELATED APPLICATIONS

This application claims priority to India Patent Application No. 4072/CHE/2015 filed on Aug. 5, 2015, the content of which is incorporated herein in its entirety.

FIELD OF THE DISCLOSURE

The present invention relates to a method and system for generating, sending, updating, and monitoring electronic documents (eDocuments). More specifically, the present invention relates to generating, sending, updating, and monitoring eDocuments based on source documents created in Enterprise Resource Planning (ERP) software.

INFORMATION

Every country and process has different technical requirements for the transmission of eDocuments. These technical requirements can greatly vary. Business-to-Government (B2G) and Business-to-Business (B2B) communication is a worldwide trend that expands quickly every year. Companies in countries, e.g., Brazil and Mexico, may be required by country law to send electronic invoices (i.e., eDocuments) to the government for approval for transactions that are, e.g., posted in their ERP software. The number of individual countries having regulations, which require different technical requirements, has increased in recent years. In another example scenario, the government is not an active party in the communication. There, e.g., eDocuments may be used to automate business flows. These technical requirements could be, e.g., format requirements, authentication requirements, legal requirements, etc.

To illustrate, a business entity in a particular country may create an invoice (i.e., an eDocument) when doing business with another entity, which may be another business entity or the local government. When creating this invoice, the business entity is required, by government regulation, to conform the invoice to specific technical requirements. These technical requirements compel the supplier to carefully manage and monitor all of its eDocuments for compliance. This monitoring and managing forces the supplier to expend significant amounts of resources, since these regulations can be complicated, vary greatly between individual countries, and are usually specific to a single type of eDocument.

Once the business entity has ensured that its eDocument complies with the technical requirements and government regulations, the business entity submits the eDocument to a common authority (i.e., government agency), so that the eDocument can be reviewed for compliance. Only after the common authority confirms that the eDocument is compliant, is the business entity authorized to transmit the eDocument to the other entity.

The process of creating and exchanging everyday business documents becomes a highly technical and time-consuming process, which requires different, individualized solutions for each individual country and each type of eDocument being exchanged. The process can involve significant expenditures of resources to ensure that exchanged eDocuments are legally compliant with the relevant technical regulations.

Traditional methods attempting to solve these issues only a particular country and a particular eDocument type. The existing systems still require significant amounts of resources to complete, and once the systems are produced, they have very little synergy and are not easily scalable or transferrable due to the wide variety of government regulations and eDocument types. This inefficient use of resources is joined by a large lack of quality and integration issues. The customers that do business in different countries must execute varying different solutions to tackle and solve a similar situation.

This issue becomes particularly relevant in regard to large, multinational corporations, which operate in many different countries, and therefore, are required to comply with a wide range of different technical requirements.

DETAILED DESCRIPTION

In an embodiment of the present invention, the eDocument framework system provides a set of tools to allow the incorporation of country-specific solutions without the need to start from scratch every time. The eDocument framework system is prepared and/or configured to manage, generate, send, update, and monitor the eDocuments. The eDocuments can be sent to local authorities, business partners, or other recipients. Functionality is provided by the eDocument framework system, which allows the framework system to be easily expandable to include additional details and particularities for a specific country and process. This expansion can be accomplished without expending significant amounts of additional resources and effort to keep uniformity. The eDocument framework system also reduces maintenance costs.

To accomplish this, in an embodiment of the present invention, the eDocument framework system includes of a number of functions described below that enable the eDocument framework system to highly automate the process of managing, generating, sending, updating, and monitoring eDocuments.

In an embodiment, the data collection part is part of the application, and it must be able to retrieve the required technical requirements for the desired eDocument, map it to an appropriate communication format, and send it out through a web service during a certain step of a process (for example in the sales division (SD) of ERP, during post goods issue).

In an embodiment, the data collection is implemented in all applications that generate eDocuments. One example is through the backend of ERP software. For electronic invoicing that can be in the following in the ERP software: Sales and Distribution (SD) Financials (FI); Financial Cost Accounting (FI-CA); Real Estate (RE-FX); and where industry specific invoicing is done. Further aspects or modules of the ERP software can include; Sales and Distribution of Delivery Goods Issue (SD Del GI); Sales and Distribution of Transportation Planning (SD Transportation Planning); Sales and Distribution Bills (SD Bill); Sales and Distribution of Logistics and Material Management (MM); and Industry Specific Utilities (IS-U). In an embodiment, the eDocument itself includes the source data when electronic documents have to be created without a standard document. Examples of this are incoming documents.

In an embodiment, the actual communication is performed outside of the eDocument framework system. The eDocument framework system is built to communicate and interact with a cloud services provider, for example, SAP Hana Cloud Integration (HCI). It is possible to use other communication platforms, which would be a customer specific solution. In an embodiment, the communication platform is decoupled from the eDocument framework system so that any application is able to use the HCI communication flow being offered for a certain use case and/or country. In an embodiment, the communication platform is a cloud application, making it independent of installed bases and allowing faster deployment and maintenance. Incoming electronic documents may be generated outside of the ERP software. In an embodiment, the eDocument is sent to an email account or to an HCI tenant of the customer.

In an embodiment, the framework system initiates a pull mechanism to retrieve these objects, store them as part of existing eDocuments or create new eDocuments, depending on the content of the information received.

In an embodiment, the eDocument framework system sends different messages regarding current eDocument status and different events affecting eDocument (e.g., user actions in an interface). For example, response of such messages (approval, response, status response, etc.) is be received and processed. To accomplish this, for example, different interfaces are monitored in the eDocument framework system. In an embodiment, versioning of the interfaces can be effected in order to allow interface format change with time. In an embodiment, the eDocument framework system stores relevant changes to the eDocument in a database.

FIG. 1Ais a simplified view of the system landscape. The system landscape100includes a backend101, a cloud services provider107, and a local authority112. In an embodiment, the backend101is ERP software. The backend101can also include eDocument framework system102. The eDocument framework system102includes a mapping application103and an application interface framework (AIF)104. The back end101ERP system can also include additional software applications105and106, where the source documents of the eDocument Framework system102can be generated. Additional applications can include SAP APPL6.00or SAP Netweaver.

According to one embodiment, mapping application103is fully included within the backend101, and all processes related to mapping data are performed in the backend101. This allows for all relevant information to be presented in the backend101, which does not require the cloud service provider107to retrieve information from the backend101for processing. Locating the mapping application within the backend101also creates several advantages, for example: prevention of redundant data from being transmitted; easier mapping and analysis of the generic structure; customer extensions do not have to be added in the cloud services provider; easier testing and troubleshooting; no requirement for customer proficiency in Advanced Business Application Programming (ABAP) or cloud service provider; reduced testing effort since the information only needs to be mapped once from the source structure to the country/eDocument type specific format; and business monitoring is concentrated in the back end101.

Application interface framework (AIF)104can be included in the eDocument framework system. AIF104defines and manages outbound and inbound message processing. Although AIF104handles a number of formats, a web service definition language (WSDL) can be used in connection with the cloud services provider107. In a number of cases, the final destination does not handle web services. In those cases, emails have to be sent with extensible markup language (XML) content. The version of the message used in the AIF104is determined in the eDocument framework system102and not in the AIF104. The functionality of AIF104is more fully described below.

Cloud services provider107can be SAP HCI, for example, and can include integration flows108. Integration flows108are a Business Process Model Notation (BPMN) based model that can be executable on the cloud services provider. Integration flows108can include technical requirements related to individual Country A109, Country B110, and Country C111, etc. Integration flows108provide communication between the cloud services provider107and the local authorities112, which can be implemented through Webservices113. Integration flows108also provide validation, approval, certificates, registration of created eDocuments, and digital signatures for transmission of eDocuments.

FIG. 1BandFIG. 1Cillustrate system architecture according to particular embodiments.FIG. 1Aillustrates separate ERP divisions114(i.e., Legal Reports, SD Del GI, etc.) within the ERP software115can communicate division specific data to the eDocument framework system102. This information can then be processed using the country specific settings in the eDocument framework system102and submitted to a cloud services provider107. Subsequently, the cloud services provider can transmit the different types of processed eDocuments117to their respective local authorities112.FIG. 1BandFIG. 1Calso illustrate the scalability of the eDocument framework system102with regard to adding new ERP divisions, new countries, and/or new types of eDocuments.

FIG. 2Ais a simplified block diagram of the eDocument framework system102according to an embodiment. eDocument framework system102can include document process module201, process manager module202, interface connector203, partner connector204, eDocument interface205, and eDocument206.FIG. 2Aalso illustrates how eDocument framework system102can interact with other components within the solution landscape: users216, source document217, maintained document218, partner service provider211, and cloud services provider107. In one particular embodiment, a user216can interface with user interface205located within the eDocument framework system to perform certain tasks such as monitoring and viewing the history of the eDocument206. Additionally, user216can create a source document217, which can be transmitted to and received by the process manager module202. Alternatively, process manager module202can receive a maintained document218.

eDocument framework system102can also be configured to communicate with partner service provider211via partner connector204. The partner connector204can be used for any type of communication with a partner service provider, be it customer, vendor or business partner. Possibilities are for example: printing, generation of pdf files, XMLs, and emails with attachments. This is meant for interchanging with all partner service providers except for tax authorities. There is no limitation on the interface technology here.

In one particular embodiment, eDocument framework system102communicates with cloud services provider107via interface connector203. Interface connector203prepares the eDocument for transmission and creates the message structure and the mapping of the source document to the message structure. This can be done in AIF104or in a Custom Business Add Ins (BAdI). The number of ways to communicate using this BAdI is limited to Custom and Advanced Business Application Programming (ABAP) Proxies or XML via the AIF104. The choice of the interface connector203has three dimensions. First, the specific interface technology. This choice can be made per Company and eDocument type. AIF104content can be communicated in the following ways: as Webservices or providing an XML for subsequent processing. Alternatively, an AIF custom build can be used. Second, the choice of the interface itself. This choice depends on the source document structure, the process step/action, and the content (i.e., the actual source document). The AIF104is capable of choosing the correct version for the interface on the basis of the provided information. Third, the choice of the cloud services provider107. This choice can be made per Company and eDocument type. Possible alternatives can include, for example, service orientated architecture (SOA) manager port, or a request for comment (RFC) destination. Cloud services provider107can include a cloud based message system213. Cloud based message communication platform212can be, for example, SAP HCI. Cloud service provider107can also include other platforms214.

FIG. 2Aalso illustrates interaction between cloud services provider107and local authority112. Local authority112can be configured to exchange eDocuments with cloud services provider107via an eDocument processor215.

As further illustrated inFIG. 2A, eDocument framework system102also includes document process module201. Document process module201is found within standard applications and is the starting point in transforming standard documents into an eDocument206with the correct, legally required format. Document process module201is where the eDocument206is created on the base of source documents210, which were created in standard ERP Alternatively the document process module201can include functionality wherein an eDocument206is created on information that will be included in the eDocument206itself. The start of the document process module201is a hook in a standard application or the start of automated processing of incoming eDocument206. The original document process module201is more fully described below.

eDocument framework system102also includes process manager module202. Process manager module202performs the following functions: determining possible subsequent steps on the base of the status of the eDocument; determining the new status for an eDocument on the basis of the execution of a process step; triggering the execution of the process step; translating the user interface or program action in a process step to be executed; and verifying authorization for a process step. The process manager module202can also be configured to communicate with source document210, company data209, and master data208. The process manager module202functionality is more fully described below.

eDocument framework system102also includes eDocument interface205. The eDocument interface allows for the monitoring and processing of eDocument206. Each type of eDocument206will have its own set of process steps. All steps that can be relevant for manual processing are present in the eDocument interface205. The eDocument interface205is more fully described below.

FIG. 2Bis a simplified flow chart illustrating the basic functionality of the eDocument framework system102. The eDocument framework system102can be initiated during process223, when the system receives a document from either a user created document (i.e., source document217) or a maintained eDocument218. Next, in process224, the eDocument framework system determines the eDocument type and required process. In one particular embodiment, the eDocument framework system can use the cloud services provider107and/or the eDocument206itself in carrying out the mapping process.

Once the necessary technical requirements have been determined, process225generates an eDocument with the necessary technical requirements, and process219displays the eDocument to a user. Once displayed, process220allows the eDocument to be monitored and/or modified by the user. Process221updates the eDocument206. Process222prepares the eDocument for transmission to either the cloud services provider107or a partner service provider211. If transmitted to the cloud services provider107, the cloud services provider can subsequently submit the eDocument to the local authorities112.

FIG. 3is a simplified block diagram of the process manager module202according to an embodiment. Process manager module202determines the configuration of a specific eDocument206with respect to the process steps, statuses related to process steps, and actions resulting from these steps. In the process manager module202, the configuration for a specific eDocument type with respect to the process steps, statuses related to process steps, and actions resulting from these steps can be found. A process consists of a number of process steps/actions. A process step action can be a function module or an interface, for example, create/modify the eDocument and create eDocument history. The entire handling of the eDocument206is done through the process manager module202. The configuration of the processes and related process steps are Country and eDocument type specific. The process manager module202will invoke the processing in the local coding and does not make any changes. The process manager module202is also responsible to verify if the user is authorized to perform actions in the framework system.

Process manager module202operates as follows: a request for a process step301or get allowed step302is initiated, and the response is transmitted to the process manager module202. Process303authorizes the requested process301or get allowed step302, and determine allowed process step304then determines the allowed process steps based on eDocument206, and can include, for example: process307, process step308, allowed process step309, or process status flag310. Start process step305initiates the requested and authorized process step. The selected process step is transmitted for execution to processing eDocument type312. The process step is executed at execute process step313, and the process manager subsequently determines status flags at process306.

FIG. 4is a simplified block diagram of the implementation of an eDocument according to an embodiment. The eDocument206can include the status and process handling fields, as well as document type, organizational data, and the identity of the logical system. Each country will have one or more eDocument types. These consist of a header that is shared across all eDocument types and one or more country specific structure(s). Naming of the specific structure will be in accordance with the names used in the country. The source document for the eDocument can differ. It is possible that eDocument types and process are shared by documents from various sources. For example an e-invoice can be generated in SD, FI and industry solutions. Field names are assigned dynamically in the cockpit. It is therefore important that the names of the fields are unique within all eDocument databases401-405. Each eDocument206can include the following: country specific eDocument database401; eDocument source file402; eDocument history database403; eDocument file database404; and eDocument reference database405.

Country specific eDocument database401holds the relevant data for the country format. For each eDocument206, one country specific database401is present. If large structural differences exist for document types used in the country, then more than one country specific eDocument database401can exist. It is also possible that a country implementation requires a set of country specific eDocument databases401such as header, items and tax tables. It is also possible that no country specific content is present.

eDocument source file402can include the file that holds the source information for eDocument206.

eDocument history database403can be a copy of the eDocument206, and can include the content of the generic table at a point in time. The execution of a process step can add an entry in this table. eDocument history database403can include the process log of the eDocument206as well. Relevant changes to the eDocument206will be recorded here. This is achieved by making a copy of eDocument206, storing it in the eDocument history database403, every time that a relevant change is made to the eDocument206.

eDocument file database404can include the files, such as XML's and mails that are relevant for the eDocument206and have been used in communication. Several files can be added within a process step. The type of file is classified by a file type (must not be confused by format type). eDocument206can include a forward reference to the eDocument file database404. This functions when one file is created in a step. It is however possible that several files are attached during a step. For that case a backward reference to the eDocument206and/or eDocument history database403is present in the eDocument file database404. A file type is present to supply an easily understandable semantic meaning of a file, and the possible file types are defined per country in configuration tables of the eDocument framework system102.

eDocument reference database405can be used to include a list of documents that are relevant for the eDocument206. An example is the daily report for a specific type of invoices. The identifications of all relevant documents are kept in this file. This table will include references to other, related documents. A Reference Type defines the type of document (e.g., eDocument206or source document217) that is referred to. A sequence number that is independent on the number in the eDocument206will be part of the key.

FIG. 5is a simplified sequence diagram of the document process module201according to an embodiment. The document process can be carried out in the following steps:

First, the document process is initiated at hook501. Next, the eDocument is prepared at504. Next, message505determines if the eDocument206needs to be generated for the company/source document combination. Message506calls a constructor on the basis of the country and corresponding eDocument subclass. Message507calls the corresponding subclass from the country specific database207, and message508sends the corresponding subclass and eDocument type to the eDocument. Message509indicates the transfer of the eDocument type from the eDocument206to the country specific database207when the eDocument type has been entered manually by the user.

Messages510indicates that additional filtering can be performed on the basis of document type and other information. Additional filtering can include, for example, a customer BAdI, which can be available to provide additional filtering and to change the standard eDocument type determination.

Next, if the eDocument206is to be generated, message511returns an eDocument instance from the country specific database503to the eDocument206. Message512returns the eDocument instance from the eDocument206to the hook501. An eDocument is then generated at513.

After generation of the eDocument, message514returns an eDocument instance from the hook to the eDocument206. Message515sends the country specific additional eDocument data to the country specific database207. Message517indicates that the country specific additional eDocument is saved to the country specific database207.

The eDocument instance206and the country specific instance are stored if both messages518and519return success.

FIG. 6Ais an exemplary user interface. The eDocument framework system102can have a user interface600to display the documents, their status, and their processing history. User interface600can include a window for selection of parameters601, a window for selecting eDocument types602, selection of eDocument billing documents603, eDocuments accounting documents604, eDocuments delivery documents605, and other options for eDocuments606.

Through this interface, a user to able to monitor and/or modified a specific eDocument. The user interface will allow appropriate actions to be taken when an eDocument cannot be processed automatically. The buttons displayed depend on the country of the selected company code in the window for selection of parameters601. For the eDocuments, it is possible to view the source documents by type in the window for selecting eDocument types602, and/or by creation date (interval)609. Source documents that should have had an eDocument created can be selected through the window606.

FIG. 6Bis an exemplary eDocument user interface607. eDocument user interface607includes the details of the eDocument. It allows access to the source documents and also can include an AIF user interface for monitoring at message level. Monitoring at message level allows for viewing of the originating document and the resulting document.

FIG. 6Cis view of an exemplary history user interface608, which allows viewing of the eDocument history database403. The history user interface608displays the eDocument history609. Additionally, for the eDocuments, it is possible to download the files generated or retrieved in the AIF user interface, eDocument user interface, and/or the history user interface608that have been sent or received during the different process steps.

FIG. 7is a simplified block diagram of the interactions between the system and the application interface framework. A user702interacts with the eDocument framework system102, to initiate the resubmit program704, which receives the specified eDocument206from the eDocument database502. Resubmit program704submits the eDocument206to the interface connector203. The interface connector203interacts with AIF104, and is configured to send the eDocument206to AIF104.

AIF104receives the eDocument via AIF connect trigger707. AIF connect trigger707processes the eDocument206via several processes706: first initial mapping715, first mapping716, checks717, proxy718, first actions719, new globally unique identifier (GUID)720, second initial mapping721, second mapping722, and second actions723. These processes interact with the AIF database724. Additionally, if an error occurs during the processes706, the error is transmitted to an error collector725, which is then transmitted to error handling708process of the AIF104. The error is subsequently communicated back via communicate process709to the eDocument framework system for further processing. Additionally, first initial mapping715can transmit a result to AIF request mapping712, checks717can transmit a result to AIF generic map check713, and second initial mapping can transmit a result to AIF response mapping714.

During the processes706, upon completion of the first initial mapping715, an AIF request mapping is generated. Upon completion of the checks717, an AIF generic map check is generated, and once the first actions719process is completed, a send generic action710is generated and transmitted to the eDocument framework system. After the second initial mapping, an AIF response mapping714is generated, and after the second actions723process is completed, a response generic action711is generated. The response generic action711is also transmitted back to the eDocument framework system102.

FIG. 8is a simplified diagram of an exemplary database for use by the eDocument framework system102. Database800is a listing of the country specific additional data arranged by country. Database800can include global database801and country specific database802. Global database801can include the following databases: eDocument database502; eDocument history database403; eDocument file database404; eDocument reference database405; and contingency database807.

Country specific database802can be divided into particular country databases. For example: Italy database808; Peru database809; Chile database810; Spain database; and others811. Each particular country database808to811can further include individualized databases, which can relate to specific technical requirements for the respective countries and eDocument type. For example, the Italy database808can include an invoice database813, which includes all relevant technical requirements for invoices in Italy. Also, the Italy database808can include a notification database814, which includes all relevant technical requirements for legally compliant notifications in Italy. The Peru database can include its own specific invoice database815, invoice summary database816, and a voided document database817. Likewise, Chile can also include its own invoice database818, invoice summary819, and voided document databases820. Spain can include its own invoice database821as well. As can be understood by the exemplar structure of the database800, the eDocument framework system is easily scalable.

FIG. 9is a simplified diagram of an eDocument assigned process. Each eDocument206will have a process assigned. This defines the business process. When the eDocument is created together with the process901, a process version904is determined. The process901will have an assigned list of valid process steps906and a list of valid status flags902. Process901will also have assigned one or more process versions904. One particular process version904will have assigned a list of process steps906that are valid for that process version904, and an ordered list of status flags902that can be set in that process version904. The existence of process versions904allows changing the behavior (i.e., the valid steps, and the valid status flags) of a process along time.

The process901will consist of one or more process steps906. A process step906represents an action in the eDocument framework system. The action can, for example, be the triggering of an interface, printing or cancelling of an eDocument. The last process step906is included in the eDocument206. Each eDocument206type can have a configurable set of processing steps906. Although the eDocument type is country specific, the country will not be part of the key. The eDocument type is thought to be globally unique. The method and the class for the method that will execute the step are defined as part of the table.

On the base of the status of the eDocument206type, certain subsequent process steps906are allowed for the different types. The allowed steps are determined by verifying the status indicators that are relevant for each step. If these are set, then the step is allowed. The process steps will result in another state of the eDocument. This other state will be reflected in Status flags902. The process status flag position903assigns the flag to a specific position in the status field in the eDocument database502. A process status flag902can be assigned once per version. The process step version905can be the object used during runtime. The process step version905is the valid steps for the version.

FIG. 10is a simplified diagram of an exemplary method of processing classes.FIG. 10illustrates the interaction of AIF104, Resubmit report1001, communication1002, application1003, persistence1004, database1005, and mapping106. Communication1002, application1003, persistence1004, and mapping1006can include specific technical objects that allow interaction.

Communication1002can include class CL_EDOC_INTERFACE_CONNECTOR1111, which encapsulates interface connector logic. eDocument framework system102can instantiate this class and call different methods when the interface connector is required.

Application1003can include the following classes: CL_EDOC_PROCESS1112; CL_EDOC_UTIL1113, which includes eDocument utilities; CL_EDOC_SOURCE1114, which includes eDocument source data; CL_EDOCUMENT1115, which includes eDocument class information; CL_EDOC_SOURCE_XXX1116; and CL_EDOCUMENT_XX1117(XX stands for country specific class).

Mapping1006can include the following classes: CL_EDOC_MAP1121, which includes eDocument mapping information; CL_EDOC_MAP_AIF1122, which includes eDocument Mapping and encapsulates AIF mapping; CL_EDOC_MAP_CUSTOM1123, which provides common interface to retrieve fix values maintained in AIF104or retrieve by a BAdI; and CL_EDOC_MAP_XX1124(XX stands for country specific class).

Database1005can include the following: source documents tables1007; country specific application tables1008; application tables1009; and configuration tables1010.

FIG. 10generally illustrates how each of the communication1001, application1002, persistence1005, mapping1006, and databases1005interact with each other in order to processes the respective classes. Additionally,FIG. 10illustrates the interaction between the classes included within each of the communication1001, application1002, persistence1005, mapping1006, and database1005.

As used in the appended claims, the term “computer-readable medium” can include a single medium or multiple media, such as a centralized or distributed database, and/or associated caches and servers that store one or more sets of instructions. The term shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the embodiments disclosed herein.

The present specification describes components and functions that can be implemented in particular embodiments which can operate in accordance with one or more particular standards and protocols. However, the disclosure is not limited to such standards and protocols. Such standards periodically can be superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions are considered equivalents thereof.

The illustrations of the embodiments described herein are intended to provide a general understanding of the various embodiments. The illustrations are not intended to serve as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments can be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments can be utilized and derived from the disclosure, such that structural and logical substitutions and changes can be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.

Also, where certain claims recite methods, sequence of recitation of a particular method in a claim does not require that that sequence is essential to an operable claim. Rather, particular method elements or steps could be executed in different orders without departing from the scope or spirit of the disclosure.