HK1208570B - Method and system for providing customized network - Google Patents

Description

Method and system for providing customized network

Cross Reference to Related Applications

This application is a continuation of U.S. application Ser. No. 10/553,715 filed on 12/4/2007 as a national phase of International application No. PCT/US04/11878 filed on 16/4/2004 as filed on 7/5/2003 as claiming priority from U.S. provisional patent application Ser. No. 60/468,681 filed on 16/4/2003 as well as U.S. provisional patent application Ser. No. 60/463,201 filed on 16/4/2003 as incorporated herein in its entirety.

Background

The use of communication networks for collecting and transmitting information using the internet is widespread. These networks are typically accessed through the use of desktop and laptop computers (PCs), and also through wireless networks, such as through Personal Digital Assistant (PDA) devices and cellular handsets. However, many of these available networks do not allow for secure transmission (i.e., encryption) of data, flexibility in how data is grouped and shared, and/or the manner in which different and traditional databases and systems are connected. In addition, many of these networks require batch processing (i.e., replication) and/or a wired connection to a host computer network, such as synchronization processing (hotspot) for transferring data from the PDA to other remote terminals.

Data exchange methods used by enterprises involve facsimile and electronic data transmission, e.g., via electronic mail, electronic data interchange ("EDI"), etc.; these methods have several limitations. EDI uses a private network that is restricted to enable only certain transaction data to be exchanged. Furthermore, EDI is very expensive to implement for individuals and small corporations as well as difficult systems.

The deployment of long-standing web services XML-based technology has not been completed, and the technology lacks sufficient security. In particular, some essential elements of the web services architecture are not yet in place. Moreover, programming using an XML framework is often complex and more difficult than other programming languages.

Furthermore, conventional data exchange frameworks typically use complex architectures, requiring dedicated networks. This complexity provides less flexibility in grouping and manipulating data and makes it difficult for users to customize their networks.

Disclosure of Invention

A cloud-based method, system, and computer-readable medium for providing a secure computer network for real-time transmission of data is provided. The data is grouped and stored according to user preferences. The transmitted data is encrypted, decrypted and verified by the system (assuming the user identification/password is verified). The system can enable the use of a customized user interface for the data; these user interfaces are driven by customizable web scripts. The web page script may run in a virtual machine based environment.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Drawings

The foregoing summary, as well as the following detailed description of embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the implementations, there is shown in the drawings example architectures of the implementations; however, the practice is not limited to the specific methods and instrumentalities disclosed. In the drawings:

1-7 are schematic diagrams illustrating steps of methods and systems implemented as described herein, and any corresponding computer readable media.

Detailed Description

Methods, systems, and computer-readable media are provided for collecting, storing, and communicating data (e.g., for medical or legal billing information) for any associated application, and/or providing goods and services (e.g., food, consumer electronics, etc.) to customers.

In one implementation, the customized application/software enhancements are located on top of existing legacy systems, allowing enterprises to exchange data in internal corporate departments, and between external enterprise partners. Preferably, an application service provider ("ASP") is associated with various operational aspects of the system of the present invention via a computer network. In one implementation, the data and program scripts are stored at the ASP to minimize the hardware requirements for each user. The system is configured to enable it to be continuously updated and upgraded at the ASP level with little or no need to update the local user's network hardware (server), local hardware (PDA, PC, smart phone, media player, etc.) or software.

An ASP is also a data/information service, a network developer, an application or software provider, a hosting service, a data interface, and an information technology support group. In some implementations, an ASP that includes processing and storage capabilities may be implemented using what is commonly referred to as a cloud-based computing system or simply "cloud". In cloud computing, the processing and data resources used by an ASP can be abstracted among or between one or more computers and/or computer networks that make up the cloud. The provider of the ASP may contract with one or more cloud-based computing service providers to allocate computing and/or storage resources for implementing the various ASP services described herein. An example of a cloud computing service includes S3 provided by amazon.

Each user of an ASP may have its own portal provided by the ASP for collecting, grouping, running, storing, encrypting, transmitting, receiving, authenticating, and/or decrypting data. For example, a merchant may have a portal with data and fields customized for the merchant's business. In particular, a food provider can have a portal customized for its menu and price to enable users to order food products from a network. The user inputs information to the food provider's portal through a customized user interface, and the data is encrypted for transmission to the food provider. The customized user interface may have a pop-up menu that provides options for the user to select, for example, a main course, side dish, dessert, etc. The food provider decrypts and validates the data (e.g., food selection or credit card information) to process the order. At the same time, the system replicates the transferred data for validation and backup and maintains the database using the state of the data transfer.

The ASP generates web scripts via an agent (e.g., zotbot) that the user uses to enter, store, and/or store data. These web scripts are stored by the ASP and are accessible to the user. The system receives data from the user and stores it in the system database and, optionally, in the user's database. In some implementations, the web page script may be generated by what is referred to herein as a parent web page script. The parent web script may dynamically generate one or more daughter web scripts based on data collected by the parent web script, data stored in a system database, or data stored in a user's database. The mother web page script and/or the daughter web page script may provide various user services and merchant services as described herein.

The ASP can also generate and provide services through one or more virtual machines. For example, the ASP may generate and maintain virtual machines for some or all of the web scripts derived or generated by the ASP. Whether or not the web page script is running in a virtual machine, it may be specified by parameters in the user or system data. Each virtual machine may run using a "clean" version of the operating system and thus may provide protection for a user of the associated web script against viruses or other hazards associated with a compromised computing environment. In addition, each virtual machine may be provided with virtual memory, or a virtual database, for execution of the web script, which further proves protection of sensitive data associated with the web script. The above process may be automated using one or more web scripts.

The ASP may be accessed over a land-based line, using a modem for DSL, telephone, or cable connection, over a conventional PC or wireless connection (e.g., through a PDA or cellular handset), using any suitable wireless technology that allows for the secure transmission of data (e.g., WiFi). The transmission data is stored in a database of the ASP (i.e., a memory allocated to the ASP in the cloud) to enable generation of a bill for the transaction from the web script. The bill can be automatically processed by the web script. The bill from the ASP can be based on a percentage of the selling price of the transaction being performed, or can be a flat fee per transaction or per transmission. Alternatively, the user can pay according to a fixed, predetermined period, e.g., yearly, semi-yearly, quarterly, monthly, weekly, daily, or hourly, which allows the user to have an unlimited or predetermined number of transactions during the billing period.

The ASP tracks the transmission of data (whether encrypted or unencrypted) and maintains the database with the status of each data transmission in the cloud. Thus, it can provide reports on data being entered, grouped, encrypted, authenticated, decrypted, transmitted, etc.

The existing user or the new user may send or receive data, possibly in response to a communication generated by the ASP, such as an advertisement sent via email (e.g., a special offer by a merchant-user). The portion of the communication is the same for all system users or is customized based on the characteristics of the returning users. The characteristics of each user are maintained in the system in a historical database containing records for each user in the cloud. The historical database of user characteristics can also be used to verify data transmitted to and from the user.

The ASP may allow a user to specify or select a destination device for which data is desired to be received and/or for viewing the user interface. For example, initially, a user may establish communication with an ASP through a form using a smartphone, but may desire to interact with the ASP through another device (e.g., a television). Thus, the user may select an option on the form to view the form and/or data provided by the ASP on the television. The ASP may then format the forms and/or data for viewing on the television and push the forms and/or data to the television at the request of the user.

The ASP may also interact with or include a voice server. The voice server may provide one or more interactive voice features to a user of the ASP. For example, the ASP may use a voice server to read out data from fields of the user interface to the user through a cell phone or other device. Further, the voice server may convert voice data received by the ASP into text for processing by the ASP. The voice server may operate on multiple languages and may provide translation services to users of the ASP.

Generally, referring now to how certain exemplary implementations operate, a user inputs information into a displayed dynamically generated user interface (i.e., a web page or form). The customized user interface enables a dynamic user interface (e.g., a dynamic web page) to be generated for a user by one or more web page scripts. The format can be used by a PC, handheld computer/PDA, cellular telephone, smart phone, cell phone, television, media player, video game console, or any other type of computing device. The form may be a voice-enabled form and may include prompts that are read aloud to the user and enabled by the voice server. In one implementation, the information for each user interface is stored in a parent web script, which is an example of an agent or so-called zotbot.

The data is then validated by the web script to ensure that the form is completed correctly and the correct type of data is entered. Validation ensures that the data being transferred conforms to one or more rules for each data field maintained in the system database (e.g., the system checks the appropriate number of digits for a credit card or telephone number, and only checks the digits that have been entered, not letters). This helps ensure security and filters out spam data and malicious code fragments. The rules may be provided by a merchant or administrator associated with the services provided by the ASP. The data may also be verified using a voice recognition service provided by the voice server (if available).

After the data is verified, the data is encrypted by the web script using an algorithm (e.g., Blowfish encryption algorithm, or any other suitable, compatible encryption method) and transmitted to the recipient. The recipient may be specified by a merchant or administrator associated with the service or may be specified by a user using fields of a user interface. To improve security, the encryption algorithm can be changed periodically, or randomly. Thereafter, the data is transmitted and decrypted so that the recipient can process the data and store the data in the database. Transmission and encryption can be controlled by a module using open source code or proprietary code.

Once the data is decrypted, the data state is generated by a web script that allows one or more users to access the state information, and stored on the recipient's web server, or other storage device. Further, the ASP may monitor the transmission of data through its own server or a function provided by the cloud, and may store the transmitted data for backup and billing purposes. In particular, the ASP can use the stored data to determine the history of data transmission (i.e., any faults in how the system transmits the data) to correct a particular transmission and/or to correct any system-wide or recurring problems in the transmission. In some implementations, the mother web script may create a decryption agent when invoked by a phone (voice) or other device (data) and push the decryption agent to the user via a virtual machine.

Further, the stored data enables the ASP to charge the user for the transmission of the data, charge the user based on completed transactions, or a combination of both, depending on the network activity of the user. As described above, the system can record a trace of the timestamps in each step of the process.

As one example of a suitable application, an ASP may be used by a medical professional. The medical professional may connect to the ASP, and the mother web script may retrieve data associated with the medical professional (or an institution associated with the medical professional), and may use the retrieved data to generate a daughter web script for the medical professional based on the retrieved data. The sub-web script may be implemented by the ASP in an instance of a virtual machine. The daughter web script may provide a customized user interface that allows a professional to enter patient (demographic, diagnostic, and treatment) information. The customized user interface may be displayed on a desktop computer, a smart phone, a tablet computer, or any other device that may be used by a professional that is associated with the professional. The user interface may also be voice-enabled through a voice server. The subnet page script can dynamically detect and adjust the size and/or resolution of the user interface based on the equipment used by the professional. The medical professional may connect to the ASP using speech recognition or through a biometric device. The ASP can then communicate with the voice professional by speaking one or more prompts to the medical professional. The information used/provided by the medical professional may be sent via email, text messaging, or stored in the cloud.

The subnet page script may transmit the entered information in encrypted form to a database of the hospital and/or a database of the insurance company. The data can then be decrypted by the recipient and verified to meet the requirements of the data type and group (which may be customized by the system), or the requirements for claim payment by, for example, insurance companies and other medical payers. At the same time, the system tracks the transmission of data and maintains a database with the status of each data transmission event. In addition, the system stores the transferred data for verification and backup purposes.

Methods and systems are configured to provide a secure way of communicating sensitive patient data. The system can be adapted to comply with any reasonable requirements for data submission, e.g., to comply with HIPAA, tax returns for IRS, etc.

More specifically, referring to fig. 1, an application service provider or other host 21 implemented by the cloud has extracted sufficient user information from the master database for the corresponding application by any suitable means. This user information has been loaded into a suitable, searchable or hierarchical database 23 for use by the system described later. Preferably, the information in the database 23 is replicated from or retrieved from a master database of the client or user, however, a separately derived database 23 is also suitable. Alternatively, in another suitable implementation, the data structure can be an XML, HTML, JavaScript, HTML5, or AJAX framework, where it will often access the client's master database of associated information. In some implementations, the client information is provided by the client or may be manually entered by a user or administrator associated with the ASP. The memory associated with the database 23 may be provided by the cloud provider.

The appropriate program (i.e., one or more parent web scripts) represented by block 25 responds to the user request 27 and accesses and arranges the particular data from the database 23 for further processing by the system via various agents or similar subroutines. Program 25 may be implemented using any suitable messaging and collaboration component or database management component for multi-user access to a database and corresponding manipulation of data therein. Preferably, the program 25 processes one or more requests 27 composed by the ASP 21 using a data template 29 used by one or more additional web scripts or "agents" generated or derived by the program 25, as well as data from the database 23.

In some implementations, program 25 may derive one or more daughter web scripts 33 or virtual web scripts 33 for processing according to data templates 29 and data from database 23. In addition, data from the database and/or data templates 29 may also specify whether one or more virtual machines are created to process a daughter web script 33 or a virtual web script 33.

The interactions orchestrated by the web script 33, the agent or program's instruction set 25, the template 29, and the associated data 23 can be generalized and optimized by way of the data structure 31 for any number of different types of requests 27. In some implementations, the data structure 31 is contained in the template 29. More specifically, data structure 31 has been organized and populated by program 25 so that it can be used very efficiently in the generation of additional daughter web scripts or virtual web scripts 33. By carefully selecting, organizing, and orchestrating the filling out of the data structure 31, a greater number of web scripts 33 (i.e., daughter web scripts or virtual web scripts) can be generated corresponding to a large number of requests 27, whether such requests are part of a single application of the system 19 or between multiple applications of the system 19.

An example of a suitable data structure in the utility report extraction language (Perl) is as follows: TABLE-US-00001$ username ═ 5004; my% usernamecode (5004 > "Smith, John",5010 > "Kreiger, Maurice",5012 > "Stein, Rebecca",5111 > "Willard, Tim"); my $ usernamereference ═% usernamecode; my $ mattersreference ═ { CLIENT 101 ═ > [ "108200Davis v.Yoder", "207111Beaver v.Tom", "001800Smith v.Berger" ], CLIENT102 ═ [ "207301Son v.Tim", "107782Springton v.McDermick" ] };

TABLE-US-00002print$q->popup_menu(-name＝>"username",-values＝>$usernamereference,-default＝>$username)；print$q->popup_menu(-name＝>"reference",-values＝>$mattersreference->{$q->param("clientname")},-default＝>$mattersreference->{$q->param("clientname")}->[0])；

manipulated data 23 responds to request 27 and program 25 generates web script 33 through appropriate use of template 29 and data structure 31. This can be done in batch mode at a specified time, on demand (e.g., in the case of speech recognition), event triggered, or at periodic intervals. The web script 33 may reside in the processing of the ASP 21, or may be derived by the program 25 and provided to the web server 35, as shown in step 35 of FIG. 1. In some implementations, the ASP web server 35 may be a virtual web server and may be implemented by a cloud as described above.

Depending on the nature of the request 27, and the nature of the ASP's interaction in the request, all or part of the web script 33 may be generated at step 35. Further, at a later time, as processing of the web script 33 continues, or based on user actions or input taken with respect to the web script 33, each web script 33 may generate one or more additional web scripts 33. The web page script may be invoked using a speech recognition service provided by a speech server.

Thus, program 25 generates web page script 33, which web page script 33 is adaptive in the sense that different system-level requests arrange data and corresponding instructions differently and dynamically in response to such requests to generate an adaptive instruction set. These dynamic and adaptive web page scripts or instruction sets that are generated are referred to as "bots" or "zotbots".

FIG. 2 also details the operation of the function block 37 (FIG. 1) of the web script 33 described above. Thus, in the case of an agent's timing program, a physician's patient diagnostic program, a restaurant contractor's food redistribution program, or any of the other myriad user applications contemplated herein, the running of the web script at step 37 also involves the interaction and data transfer between the user desiring to use the system 19 and the associated data that fills out not only the generated web script, but also the corresponding database that may be used in response to the user request. More specifically, referring to FIG. 2, in one implementation, execution of the web page script in step 37 results in a user interface displayed on a user accessible device, preferably under SSL or some secure channel, e.g., a wireless handheld device or smart phone (step 41). The user interface may be a form and may be generated based on data provided by the user, data from a template associated with system 19, and also the type of user accessible device used to display the form. For example, the table may be formatted at a resolution that is optimal for the particular user accessible device that generated the request. The user interface can be voice-enabled and can be read out to the user via voice prompts enabled by a voice server.

For those applications in which a user enters data into the form, the format or content of the data undergoes various encryption and/or manipulation steps, depending on the protocol involved. Thereafter, depending on the application, the data is suitably authenticated, encrypted (step 45), and e-mailed within SSL, encrypted via SMS, sent unencrypted directly within a secure VPN tunnel, or unencrypted via secure SMS (step 47) to the intended recipient of the input data, which may be a billing processor, patient record holder, food contractor, etc., for integration into a database, etc., in step 43. Data may be entered by a user via a voice recognition program enabled by a voice server.

One aspect of the operation of web scripts that has been described is their efficient handling of sensitive data. More specifically, an encryption algorithm is selected that is readily adaptable to a variety of different applications or sub-applications of system 19. In one implementation, the open source architecture is the basis for encryption and decryption of sensitive data passing on system 19 in response to requests or the execution of web scripts. Of course, it should be understood that any number of security protocols, including proprietary architectures, may be used if desired when running web scripts.

The data entered by the user is not only sent in encrypted form to its intended recipient for further processing (step 49), but may optionally also be sent to a host or ASP, as shown in step 51. The participation of the host or ASP in data processing (e.g., receiving incoming data via email, SMS, or other means) can enhance the flexibility and functionality of the available applications for system 19. Thus, for example, based on bill pay-as-you-go, the ASP can own a multi-user interactive application. Unless otherwise stated, the user of the application can be charged for use of the system 19 based on the number of transactions he has been involved in, and such transactions can be "tracked" as they are received by the ASP in step 51, as described above.

Thus, system 19 can be configured to burden heavy users of system 19 with a correspondingly heavier financial burden, and conversely, temporary users will be responsible for a correspondingly lesser burden associated with the convenience and other benefits of using system 19. From an ASP perspective, programmers and application developers can spend time and effort developing or customizing system 19 for a user or class of users, and the cost of such development effort can be returned to the ASP over time based on the use of such functionality by one or more users. This flexibility in turn makes ubiquitous e-commerce easier for ASPs and customers, as the cost structure associated with such ubiquitous e-commerce can be created and tracked by the servers of ASPs that receive data in step 51 of FIG. 2.

One suitable system and associated method for billing for each transaction is shown in fig. 4. Data received at the mailbox server or other receiving means of the ASP at step 51 of figure 2 is manipulated by the message sending program of the ASP using suitable security measures (e.g. encryption of the data) at step 53 of figure 4 and such data from the message sending program is suitably stored on the disc 57 of the ASP. This disk 57 may be part of a number of data stores assigned to an ASP by a cloud computing provider.

Data from the disc 57 is manipulated, filtered or otherwise processed by steps 59 and 61 as appropriate so that a billing information database 63 is generated. The database 63 is in turn subject to a diagnostic program 65, a backup program 67, and a bill generation program 69, which are adapted to the financial nature of the information contained in the billing information database 63. Suitable programs include any formula, algorithm or methodology used by the ASP to attribute financial values to the use of its system so that a corresponding bill can be generated in step 71 and appropriately communicated to the user of said system 19. In one implementation, the messaging and collaboration system of the ASP uses a proxy or web script to automatically store encrypted data and state information to disk and load the accounting, state, and encrypted data into the ASP's accounting information database and check for appropriate accounting flags. The ASP can then charge on a regular (monthly) basis.

Referring now to FIG. 3, it should be appreciated that system 19 is preferably a form of "middleware," meaning that it creates an interactive structure or package for processing data accessed or entered from one or more distributed locations. While such data processing may ultimately interact with the central database, the use of such middleware, structure or encapsulation reduces the need to access the central or other master database during data processing and thus improves efficiency, speed, system performance, and produces all other advantages associated with simpler communications.

Using the middleware of system 19, the previously discussed proxy "bots" or web scripts are created to contain or access all relevant information without accessing the main database. For example, each web page script may run in its own virtual machine. This architecture limits data corruption, avoids data collisions, deadlocks, the need for synchronization over wireless or cable, and enhances performance and security. Middleware is also designed to coexist with the current processing of the system. Preferably, the system 19 is accomplished in a cloud-based architecture, and in a manner in which functionality can be added to the system without the need to customize existing applications of the system. As shown in fig. 3, much of the information processing previously discussed is performed in a layer separate from the main processing system and in a database associated with the application information. Thus, the execution of the web script discussed with reference to fig. 2 may be performed in a module 81, preferably the module 81 may be executed by the cloud in a virtual machine that is separate and distinct from the main database 99.

The transfer of incoming data from module 81 is accomplished by an appropriate messaging application, e.g. email communication in system module 83, which module 83 sends an email containing validated data to the recipient mailbox server, and to the ASP mailbox server, as previously described with reference to steps 49 and 51 of fig. 2. The middleware module is built so that data entered by the user here is checked for integrity, consistency, validity, etc. before being loaded on or transmitted to the main server of the client's system, if necessary. In some implementations, each middleware module may run in its own virtual machine.

Once the encrypted data has been properly received by the intended recipient, the encrypted data is processed independently of the recipient's disk 85, i.e., independently of the additional execution of web scripts and the additional processing of "packages" of data responsive to user requests. The recipient decrypts the data and generates the appropriate status indicator in step 87. When a program called proxy decryption is run, it decrypts the information, which is displayed on the screen of the web browser, or other user device, and creates a state information file on the web server (step 87), preferably in the cloud-based environment where the proxy decryption is located. Preferably, the state file is updated with current state information when the appropriate agent runs the corresponding task in the middleware layer, or when otherwise instructed by the system. Thus, in a food contractor application, for example, a customer places an order. The order information is processed at the middleware layer by modules 81 and 83. The ASP may derive an appropriate web script that decrypts the order information, triggers the creation of an order status file (step 87), and sends an email confirmation to the requester or customer (step 89). The order information is verified for its integrity and any payment processing is also done by the appropriate web script and loaded into the database. During processing of the food order, the status is periodically updated at various points by an agent or web script, and the current status information is reasonably obtained by providing a way for the customer over a network link or otherwise (step 97). The mother web page script can be decrypted to the user via the virtual machine or the derivative agent according to the requirements of the daughter web page script.

Depending on the particular application or user request, the data is processed such that a state information file is generated (in step 89) on the cloud-based environment in which the agent is present, where it is interactively communicated or accessed by the user in a state or other request 91. The decrypted data is stored as a file to the recipient's disk 85 (or virtual disk on a virtual machine) and is also transferred and loaded onto the master database as shown in steps 93, 95 and 97 as appropriate.

Throughout the operation of system 19, secure messaging and associated encryption and decryption protocols are used as required by the particular application.

It should be understood that the program 25 for generating web scripts may be implemented in any suitable language. For example, program 25 may be implemented in Perl, and execution of such Perl script generates corresponding HTML code. Data security is also provided by any suitable means, including SSL and VPN. Although Perl or other web scripting programs may be used, other programming languages and protocols are suitable, such as Java, HTML5, AJAX, C + +, XML, C #, and the like.

The following examples also illustrate aspects of the systems and methods described herein.

Example 1

In one exemplary implementation, the network/ASP is used in conjunction with the healthcare field. In particular, a physician examining a patient uses a tablet computer or other portable, wireless computing device to enter information about the patient being examined and/or treated. The physician's portal to the network provides fields to a customized user interface to receive information about the patient, such as demographic information, medical history, used medications, allergies, diagnostic summaries made by the physician, treatments derived from the diagnosis, and the like.

In real time, the physician is able to transfer data to the hospital or office database by encrypting the data and transferring the encrypted data. The web script may receive and decrypt the data and may validate the data against its own database. The web script may be run in a virtual machine to provide additional security. Hospital or clinic databases contain information about patients, diagnoses, treatments, or any other relevant information about patients or medication. The data entered by the physician can be validated to ensure that it is consistent with the data maintained in the hospital or office database. Alternatively or additionally, the data can be validated once entered by the physician.

Another web script could monitor data transmission and verification and could notify the physician in a timely manner if the entered data is not appropriate (or appears to be erroneous). Furthermore, web scripts allow the transmission of similar messages from hospital or consulting room databases to physicians if one of their databases generates information that the treating physician should, for example, render insurance no longer valid. At the same time, the web script stores all the transmitted data and monitors the status of the transmission. The web script can provide a user with a status report on the data being transferred and the transmission process. In addition, the web script charges the user based on a predetermined fee scheme for network usage.

In some implementations, the same or different web scripts may allow the physician to selectively display information to the patient on one or more computing devices, televisions, or other devices. For example, a physician may use his tablet computer or wireless device to cause a web script to display information relating to the patient's health on a television in the examination room. The information may include x-rays of the patient or information related to the diagnosis. Alternatively or additionally, the physician may cause information to be displayed on or sent to a smartphone or cell phone associated with the patient. In some implementations, the information may be displayed in response to one or more triggers, such as voice instructions from a doctor, RFID tag, or device, that convey the information within range of a recipient on a television or other device, or a biometric tag/device associated with the television or doctor.

The ASP application described above can also be used to support other members of the healthcare field. For example, a psychiatrist can use it to collect patient information during a treatment session. In addition, the physiotherapist can use the network to map the patient's progress of rehabilitation and compare with previous segments.

Example 2

In another exemplary implementation, the network/ASP is used in conjunction with the food service industry. In particular, a restaurant (or food distribution and/or take-away store) maintains a portal in the network that includes its daily menus and an order form with prices. Users of the network can access the portal or web site of the restaurant and place an order by entering and transmitting data (optionally encrypting the data, for example, if credit card information is provided). The table of restaurants may have line items to select from the table, duplicate a conventional restaurant menu or pop-up menu. The table has items (e.g., daily or weekly specials) that the restaurant offers during a particular period. These line items or pop-up menus can be changed, for example, if a restaurant changes its menu or lacks a particular item.

Another example of a data field for a table for a restaurant is a food pick-up location. The options can come from a list of available pickup locations (or a pop-up menu). The user will typically pick the most convenient location; however, if a location reaches capacity, the location can be removed from the list so that it is no longer available for selection.

The recipient restaurant verifies the order data (e.g., to ensure that the customer name contains only letters) and processes the order, or if the data in the order is inappropriate, notifies the user in a timely manner by transmitting a message over the network. Possibly, the restaurant encrypts data about the final price and transmits the data and feeds back the time the food is ready to the user by the same process.

During order processing, the network receives the transmitted data and stores the transmitted data for backup and validation purposes. This enables the network to charge the user for the transmission of the data, or based on the completed transaction, and act as a backup copy of the data being transferred.

The web script is capable of processing messages, authenticating users, decrypting data, authenticating data, and loading data into a database. The web script can also process the bill. The web script may also read data aloud using the functionality provided by the voice server.

Example 3

In another exemplary implementation, the ASP may be used in conjunction with a law firm charging system. The web scripts of the ASP create a custom portal for each user, with fields containing a pop-up menu that displays the allowed options for each field. Alternatively, the fields may be read aloud to the user via a voice recognition system enabled by a voice server. This field may be the user identification, the type of work, the time spent on the task, the task description, the customer and event names and numbers, the billing rate, etc. The fields may be specified for the legal form by a template or data stored by the ASP and associated with the legal firm.

The agent can input the time spent on the event and a description of those events from a tablet, smartphone, or other remote and/or wireless source. This can be entered at the time of performing the work to be transferred (possibly wirelessly) to a central billing program of the law firm, which generates a bill for the client. Data from the user is encrypted (which is particularly important for legal services based on the need for client confidentiality, i.e. agent-client rights), decrypted at a central location in the legal firm, and verified. The application may be implemented by a web script and may be run by an instance of a virtual machine.

As shown in fig. 5, with respect to the essequietimebot application, legitimate billing data (e.g., client, event, description, time spent, etc.) is entered by the user through a wireless PDA, smartphone, or tablet. Alternatively, the user may enter data by reading the data aloud through a voice port or other functionality provided by a voice server. The data is transmitted through an EsquireTimeBox (Web script), which encrypts and, optionally, validates the data. Each instance of the essequietimebot may be implemented by the ASP on a separate virtual machine. The data is then transmitted to the accounting processor of the law firm or to the secretary of the user, possibly by e-mail. The data is then decrypted by proxy decryption (agentdescrypt) (web script) and, optionally, verified. The decrypted data is then transmitted to a billing database for input and further processing (e.g., generating a bill). In an alternative implementation, the billing data can be passed from the user to the billing database via other web scripts (without being passed to the billing processor or the user's secretary). The bills may also be distributed or viewed by the user through a virtual desktop that has a stack of virtual bills waiting to be viewed. The bill may also be sent directly to the client by way of email.

In addition to being used for billing procedures, the ASP can also be used by agents engaged in new clients. It allows a user to enter a potential customer name remotely via a PDA or smart phone and the customer name can be timely transferred to the legal firm's database. The potential new customer name can be compared to existing customers, previous customers, or the opposite of the event being processed by the transaction to determine if the transaction can represent a potential new customer or if there will be a conflict in interests.

As shown in fig. 6, which is an illustration of another implementation of the system described herein. The system includes a mother web script 601. The parent web script 601 may be associated with a messaging and collaboration component and may be implemented by the process 25 previously described with reference to FIG. 1 or may be part of the process 25. The mother web script 601 may directly or indirectly provide all services and functionality provided by the ASP. Although only one parent web script 601 is shown, this is for exemplary purposes only; there is no limit to the number of parent web scripts 601 that can be supported. The mother web script 601 and the various components described in fig. 6 may be implemented using a cloud-based computing system.

The parent webpage script may receive a user-initiated request from the source device 603. The request may be a request to receive access to one or more application services provided by the ASP. Source device 603 may be one of a plurality of source devices, including but not limited to: a personal computer, laptop computer, smart phone, e-reader, media device (e.g., television or video game console), cellular telephone, or conventional cell phone. The user-initiated request may also be received in various formats including, for example, an HTTP request, an SMS message, an email message, and a dual tone multi-frequency signal.

In some implementations, the request may be an internal request and may be received from an ASP. For example, the request may be a request for the mother web script 601 to perform a monthly bill generation process for a law firm.

Upon receiving the request, the parent web script 601 may generate, derive, or invoke one or more child web scripts 605. The mother web script 601 may generate, derive, or invoke the daughter web script 605 from data associated with the request, data from the database 23, or data from the data template 29.

The daughter web script 605 may be a dedicated web script that executes a particular process or application service requested by a received request. The daughter web script 605 may similarly use/access data associated with the request, data from the database 23, or from the data template 29 when processing the request. In some implementations, the daughter web script 605 may be derived or created by the mother web script 601 upon receiving a request, and may be destroyed or closed when it completes processing. In other implementations, the daughter web script 605 may persist in the cloud-based computing system and may generally become available to a user or application to process the request.

The parent web script 601 may also generate, derive, or invoke one or more virtual web scripts 603. The virtual web script 603 may be similar to the daughter web script 605 described above, except that the virtual web script 603 may run in the virtual machine 606. The mother web script 601 may generate the virtual machine 606 when generating the virtual web script. In addition, the parent webpage script 601 may assign virtual webpage script 603 access to the virtual database 607. The virtual database 607 may be a portion of the database 23 or some other database or storage device accessible only to the virtual web script 603. In some implementations, the parent webpage script 601 may copy any data from the database 23 or data template 29 used by the virtual webpage script 603 to the virtual database 607 when creating the virtual database 607.

The virtual machine 606 may allow the virtual web script 603 to run in an operating system environment that is completely separate from the environment used to run any other scripts. Furthermore, since the virtual machine 606 (including the operating system and virtual database 607) is created when the virtual web script 603 is created, it can be reasonably assured of getting rid of viruses, spyware, adware, or any other malware that may be associated with existing systems.

Although not shown, in some implementations, one or more daughter web scripts 605 may also run in the virtual machine 606. In addition, one or more parent web scripts 601 may also run in the virtual machine 606. By running the daughter web script 605 and/or the mother web script 605 in the virtual machine 606, the web script may derive the security advantages associated with the virtual machine.

Each daughter web script 605 and virtual web script 603 may also spawn, invoke, or create additional daughter web scripts 605 or virtual web scripts 603. With respect to the virtual web script 603, each additionally generated virtual web script 603 may also accommodate a unique virtual memory and may run in a unique virtual machine 606.

The daughter web script 605 and the virtual web script 603 may generate data and provide the data to one or more destination devices 610. Destination device 610 may include a plurality of devices including, but not limited to: a personal computer, laptop computer, smart phone, e-reader, media device (e.g., television or video game console), cellular telephone, or conventional cell phone. The data may also be provided in a variety of formats including, for example, HTTP requests, SMS messages, email messages, media files, flash signals, and dual tone multi-frequency signals.

The daughter web script 605 and the virtual web script 603 may provide data to the destination device 610 in a user interface, such as a dynamic web page, a voice recognition enabled prompt, an RFID interface, or a biometric interface. Other types of user interfaces may be supported and may depend on the format or protocol of the destination device 610. For example, where the data is SMS data, the user interface may simply be the user interface used by the SMS messaging application of the destination device 610. In the case where the data is read out to the user by a cell phone, the user interface may be an automated voice system that reads out the data to the user. In the case where the destination device 610 is the same as the source device 603 that provided the initial request, the data may be provided in the same user interface through which the user initiated the user-initiated request.

In the event that the destination device 610 is not the same as the source device 603, the daughter web script 605 and/or the virtual web script 603 may determine a type or characteristic of the destination device 610 and may generate a user interface based on the determined type or characteristic. The characteristics may include, for example, resolution and screen size. This determination may be made from information provided in the user-initiated request or from the database 23 and/or data template 29.

In some implementations, the source device 603 used to initiate the user-initiated request may be different from the destination device 610 that receives the data. For example, system 19 may implement a media-related application in which a user can use source device 603 (e.g., a smartphone) to select media for viewing on destination device 610 (e.g., a television). The daughter web script 605 may receive a user-initiated request that identifies a media file and a destination device 610. The sub-web script 605 may retrieve the identified media file, format the media file into a format suitable for the destination device 610 (if desired), and provide the media file to the destination device 610 using a protocol supported by the destination device 610.

In some implementations, in addition to providing data to one or more destination devices 610, the virtual web script 603 (or a daughter web script and a mother web script) can provide user access to the virtual machine 606. Through virtual machine 606, a user of destination device 610 can use virtual machine 606 and interact with virtual machine 606 as if the computing environment provided by virtual machine 606 were part of their device 610. For example, an employee of a company may use the destination device 610 to interact with the schematized virtual machine 606 after the user is using the computing environment at work. This feature is known as a virtual desktop or remote desktop. The media files (i.e., movies) on the virtual machine 606 can be pushed to a television or other media device selected by the user.

The web scripts (i.e., the mother web script 601, the virtual web script 603, and the daughter web script 605) may be triggered or invoked by one of the source devices 603 or the ASP. In addition to the source device 603 described above, the source device 603 may include a biometric device and tag, an RFID device and tag, and a smart device and tag.

Fig. 7 is an illustration of a method 700 for providing ASP services. The method 700 may be implemented by a cloud-based computing system.

At 701, a cloud-based computing system is provided. The system may be provided as part of an ASP and may be provided in conjunction with an existing client database. The system may include a user information database derived from a client database, a messaging and collaboration component operatively associated with the user information database, and at least one template configured to be populated by the messaging and collaboration component. The system may further include at least one parent web script operatively associated with the messaging and collaboration component for dynamically generating additional executable web scripts in response to user requests, independent of existing client databases, and based on accesses to the templates and the user information database.

At 703, a user-initiated request is received. The user-initiated request may be received by the parent web script and may be a user-initiated request to process information for an application provided by the ASP. The request may be received by one of a variety of source devices, including but not limited to: cell phones, smart phones, cellular phones, PDAs, web browsers, personal computers, and televisions. The request may be a number of requests including an SMS message, a packet, an email, an e-reader, a biometric device, an RFID, or a cell phone call.

At 705, one of the dynamically generated additional web page scripts is run. One of the dynamically generated additional web page scripts has been generated in response to a request based on executable code from at least one data structure included in the template. The dynamically generated additional web page script may be a daughter web page script. In some implementations, the additional web script may be a virtual web script and may be run by the cloud-based system in an instance of a virtual machine that is derived from the parent web script.

At 707, a device that receives the user interface is determined. The device may be determined by the additional web script based on one or more of a user-initiated request, a user information database, and a template. The device may be, for example, one or more of the following: a television, a smart phone, a media player, or a personal computer. The device may be different from or the same as the device that initiated the user-initiated request. The user interface may be used by a user to interact with applications provided by the ASP, and may be implemented, for example, as a dynamic web page.

At 709, a user interface is provided to the determined device. The user interface may be provided by one of the dynamically generated additional web scripts in response to a user-initiated request.

At 711, the client information database is accessed in response to a user-initiated request or in response to data input through a user interface. The client information database may be accessed as part of the execution of an application provided by the ASP.

From the foregoing description, it should be appreciated that one aspect or advantage of the systems and methods described herein includes a high-tech and cost-effective model for conducting commerce via a computer network, such as over the Internet. As other advantages, the methods and systems implement general computations and need not be limited in the geography or technology to which they are made; the suppliers and users can be geographically dispersed, use different internal computing systems, and also be connected by the system. Further, the systems and methods described herein can provide advertisements to users of the network who provide goods or services, or exchange data. The advertisement may be automatically provided in an appropriate language or demographic information.

As an example of widespread commerce, a user may place an order in Chinese to an ASP via voice, text, or some other format. The ASP can translate the order into english, process the order, and provide any confirmation data to the user in chinese. The confirmation may be provided as a phone call, a text message, an email message, a virtual desktop, a flashing light signal on a smart phone or other device, or a voice message.

As another advantage, the systems and methods described herein provide an efficient, time-saving network for engaging in commerce (e.g., purchasing goods and/or services) or exchanging data between users in real-time. The systems and methods described herein serve as a universal data interface capable of connecting different types of systems, for example, data entry methods to existing legacy systems.

In a related advantage, the method and system allow for the incorporation of modern, evolving wireless technologies into legacy systems; in this way, a wireless PDA, smart phone, tablet computer, or other computing device is able to user fill in a traditional database.

Another advantage of the systems and methods described herein may be based on validated network technologies and open source architectures.

In certain aspects, the systems and methods described herein eliminate the common, expensive and error-prone tasks of manual data entry from handwritten or typed forms, re-entry of data, verification and correction, and the inherent errors that accompany these processes.

The systems and methods described herein advantageously allow for secure, customized, and efficient groups, as well as real-time transfer of data between computer networks in a more efficient manner than previously used. The customization provided by the network enables its use by most industries, as well as for myriad tasks and transactions.

As another advantage, the systems and methods described herein provide businesses with the opportunity to include wireless mobile devices and other new forms of technology to enhance their hardware facilities at a low cost for integrating and updating the technology. In addition, it allows workers away from the office to securely connect to their business systems and exchange information in real time using common equipment.

Another advantage of the system and method described herein is that it saves time and reduces pain in methods that input data into a database or conventional system. It solves the problem of recording data due to its ease of use, flexible implementation and low cost of integration. It saves the user time by allowing the user to record data in real time due to its convenient, intuitive user interface and universal computing features. It allows for business efficiency by reducing the need to manually send, receive, and re-enter data transactions. Data need only be entered once, saving business time and money compared to multiple times (compared to some conventional data exchange systems).

Further, according to the methods and systems described herein, a user does not need to have a wired connection to a network at an office PC to input data. Users can enter data remotely from their office/home, or en route in real time, e.g., in fields or at customer locations, while they are engaged in activities they report. A user can be provided with a virtual desktop environment that mimics the computing environment that the user is accustomed to using in the office, but can be used through the user's home computer, smart phone, or other computing device. Remote access minimizes the amount of missing information, such as from transcription of a handwritten notebook, or attempts to remember the entered events and information. The method and system are simple and intuitive so that the user does not need to overcome the huge learning curve for the integration of the method and system. In addition, the method and system can be customized to the target user to further simplify and reduce the barriers to learning and successful operation.

The universal connectivity of the systems and methods described herein enables linking applications within a company internally, allowing for the integration of important internal systems. It allows users to keep their existing legacy systems, conserve their capital investment, and at the same time, provide them with a cost-effective opportunity to include new technologies, such as pervasive computing or possibly XML, AJAX, or HTML5, without losing compatibility with legacy systems. Companies can augment their existing systems with low integration costs, using custom applications and different spoken or written languages.

The cloud is used to provide a continuous upgrade path for hardware facilities to users, as the hardware facilities for owning software are upgraded and maintained by the cloud provider. The pervasive computing environment of the systems and methods described herein has robust functionality because scripts are server-based; they need not be present on the handheld device. Thus, the system is not limited by hand-held limitations, e.g., small memory size, slower processors, etc.

ASPs enable users to have customized user interfaces and applications, such as web pages or portals. Web page scripts (e.g., email agents or zotbots) can automatically create customized user interfaces or applications for the system. For example, each portal may provide a user interface with fields for entering data. Each data field may have a pop-up menu that provides options for the user to select. The pop-up menu may provide a default selection for a field to ensure that there is data in the field. The pop-up menu selection can be changed periodically, for example, on a weekly basis, using zotbot. zotbot prompts the user for the desired selection of each field or initialization information. Thereafter, it generates a suitable web script (Mod Perl or any other suitable programming language used) that creates the desired user interface. These scripts are small, easy to manipulate, and portable across multiple computing platforms.

The systems and methods described herein can also be used between enterprises as an enterprise-to-enterprise exchange. Enterprises can exchange data regardless of whether two enterprises use different computing systems and have different database programs. For example, the system may be used as a supply chain management application. That is, the provider may transmit information directly through the system to the customer. As described above, the transmitted information can be encrypted and verified, and the customer can directly incorporate the information into their database. Furthermore, it is possible to connect decentralized private systems, even if they come from different companies, acting as bridges for data exchange. Which allows businesses to establish more intimate relationships with their suppliers, distributors, and customers.

Email agents, web scripts or bot ensembles can handle messages: authenticate users, decrypt messages, authenticate data, and load data into a database. The system is flexible to enable email clients and encryption algorithms to be selected from open source architectures, proprietary architectures, and combinations of these architectures.

The methods and systems described herein also provide a way in which information can be time stamped to validate the date the information was generated or transmitted. In each step, the system can record a trace of the timestamps. The server of the system generates a number of times for the timestamp. In addition, the time of the data transfer can be recorded for different users of the system, providing further corroboration of the timestamp.

The time stamping capability is particularly useful for laboratories or inventors who want to record experimental results and/or the earliest date of discovery; thus, not only can sensitive data be securely input and transmitted, it can also be time stamped. According to the systems and methods described herein, time stamping is also used for electronic documents and/or web pages for websites whose release dates cannot be easily verified in the same manner as newspaper or magazine articles (or other documents that are first published on a paper surface) can be verified.

It should be understood that the various techniques described herein may be implemented in connection with hardware (including virtual hardware) or software or, where applicable, with a combination of both. Thus, the methods and apparatus of the subject matter of the present disclosure, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) encoded in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine (or virtual machine) (e.g., a computer), the machine becomes an apparatus for practicing the subject matter of the present disclosure.

Although exemplary implementations may refer to aspects of using the subject matter of the present disclosure in the context of one or more stand-alone computer systems, the subject matter is not so limited, but may be implemented in connection with any computing environment, e.g., a networked or distributed computing environment. Further, aspects of the subject matter of the present disclosure may be implemented in or between multiple processing chips or devices, and memory may simply function between multiple devices and/or virtual machines. Such devices may include, for example, personal computers, network servers, and handheld devices.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims (19)

1. A computer-implemented system, the system comprising:

a non-transitory computer-readable storage medium containing executable program code, the executable program code comprising a parent script having at least one adaptive instruction set that dynamically generates, derives, or invokes a child script to accept requests from an input device based at least in part on data collected by the parent script, data stored in a system database, or data stored in a user database;

providing at least one template configured to be populated by a messaging and collaboration component and a database management component;

at least one virtual computing environment is generated, derived or invoked on a physical server that includes a sub-script or virtual script containing an adaptive instruction set, wherein different system level requests arrange data and corresponding instructions differently,

wherein the sub-script or the virtual script is generated from the parent script and the at least one template, and specifies whether to create the at least one virtual computing environment to process the sub-script or the virtual script in its own virtual machine separate and distinct from the main database, and to execute in an operating system environment completely separate from the environment for executing any other script, and

wherein the sub-script or virtual script is configured to generate additional scripts as processing of the sub-script or virtual script continues based on user actions and inputs associated with the sub-script or virtual script; and

wherein the sub-script or the virtual script and the at least one virtual computing environment self-destruct.

2. The system of claim 1, further comprising:

the communication module is used for transmitting the input data from the programming module to the client; and

suitable programs for processing the input data independently of the programming module, including decryption programs.

3. The system of claim 2, further comprising:

a status module programmed to generate a message with status information and to direct the message to one of the user and the messaging and collaboration component; and

a payment module to generate an invoice for the user in response to user access to the messaging and collaboration component.

4. The system of claim 3, further comprising: a program for updating a client database using data entered by the user.

5. The system of claim 1, further comprising: a program for 1) one of sending and storing the requested first data, and 2) providing at least one of the data to one or more destination devices using a dynamic user interface.

6. The system of claim 1, wherein the messaging and collaboration component operates using a cloud-based computing platform.

7. The system of claim 1, further comprising: a program for at least one of 1) capturing and encrypting the first data from the request, 2) sending and storing the requested first data, and 3) providing the data to one or more destination devices using a dynamic user interface.

8. The system of claim 2, wherein the communication module is further to output data to one or more selected devices.

9. The system of claim 8, wherein the selected devices include one or more of: smart phones, televisions, tablets, e-readers, smart tags, bio-tags, RFID tags, smart devices with chips, and personal computers.

10. The system of claim 1, further comprising: programs capable of generating and presenting virtual desktop environments, voice recognition capabilities, and translations between one or more languages.

11. A computer-implemented method for processing information received from a user of an application, the method comprising the steps of:

providing a cloud-implemented system for use in conjunction with an Application Service Provider (ASP) that includes a parent script having at least one adaptive instruction set that dynamically generates, derives, or invokes a child script to receive a request from an input device;

providing at least one template configured to be filled out by a messaging and collaboration component or a database management component;

1) at least one of capturing and encrypting first data from the request, 2) one of sending and storing the requested first data, and 3) providing data to one or more destination devices using a dynamic user interface;

at least one virtual computing environment is generated, derived or invoked on a physical server, the physical server comprising a sub-script or a virtual script comprising an adaptive instruction set, wherein different system level requests arrange data and corresponding instructions differently, wherein the sub-script or the virtual script is generated from the parent script and the at least one template, and specifies whether to create the at least one virtual computing environment to process the sub-script or virtual script in its own virtual machine separate and distinct from the main database, and executes in an operating system environment that is completely separate from the environment for executing any other scripts, and wherein the sub-script or virtual script is configured to generate additional scripts as processing of the sub-script or virtual script continues based on user actions and inputs associated with the sub-script or virtual script; and

wherein the sub-script or the virtual script and the at least one virtual computing environment self-destruct.

12. The method of claim 11, wherein the request from the input device is received via one or more of: cell phones, smart phones, cellular phones, web browsers, tablet computers, e-readers, smart tags, biometric tags, RFID tags, personal computers, and televisions.

13. The method of claim 11, wherein the request from the input device is one or more of: SMS message, packet, email, or phone call.

14. The method of claim 11, further comprising providing the user interface comprising one or more of: providing a dynamic web page, reading instructions to a user via a telephone, and providing a speech recognition program.

15. The method of claim 11, further comprising: determining a type of device used to send the initiated request from the input device; and customizing the interface based on the determined type of device.

16. The method of claim 11, further comprising: determining a device receiving the interface; and providing the interface to the determined device.

17. The method of claim 16, wherein the device is one or more of: a television, a smart phone, a media player, a biometric device, an RFID device, a tablet, a smart garment, a smart fabric, or a personal computer.

18. A non-transitory computer-readable medium containing program code embodying an application program for performing a method of processing information received from a user of an application, the method comprising:

providing a parent script having at least one adaptive instruction set that dynamically generates, derives, or invokes a child script based at least in part on data collected by the parent script, data stored in a system database, or data stored in a user database;

accepting a request from an input device;

providing at least one template configured to be filled out by a messaging and collaboration component or a database management component;

at least one virtual computing environment is generated, derived or invoked on a physical server, the physical server comprising a sub-script or a virtual script comprising an adaptive instruction set, wherein different system level requests arrange data and corresponding instructions differently, wherein the sub-script or the virtual script is generated from the parent script and the at least one template, and specifies whether to create the at least one virtual computing environment to process the sub-script or virtual script in its own virtual machine separate and distinct from the main database, and executes in an operating system environment that is completely separate from the environment for executing any other scripts, and wherein the sub-script or virtual script is configured to generate additional scripts as processing of the sub-script or virtual script continues based on user actions and inputs associated with the sub-script or virtual script; and

wherein the sub-script or the virtual script and the at least one virtual computing environment self-destruct.

19. The non-transitory computer-readable medium of claim 18, wherein the computer-implemented system is a cloud computing system.