Abstract:
A computerized system and method for automatic assembly of a customized hypnotic or therapeutic media file is disclosed. An application collects information from a user, such as a goal to be met or a challenge to be overcome. The application may collect an audio snippet from the user and/or allow the user to record an audio snippet for insertion into the media file. The application may select components of the media file based on user inputs to indirect or direct questions. The application will generate the media file from pre-recorded and user-supplied components into a media file based, at least in part, on a time length supplied by the user. The application may be able to further adjust playback of the media file in real time so as to shorten or lengthen the file from a previously recorded playback length, while still maintaining internal cohesion and certain key message components.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims the benefit of U.S. Provisional Patent Application No. 61/946,194, filed on Feb. 28, 2014, the contents of which are fully incorporated herein by reference. 
    
    
     TECHNICAL FIELD 
     This invention relates generally to the field of hypnosis and psycho-physiological conditioning, and more specifically, to systems and methods for enabling patients or clients to create and utilize customized hypnotic or otherwise suggestive electronic media for playback, such as through a computerized application. 
     BACKGROUND OF THE INVENTION 
     Hypnosis and related forms of non-pharmaceutical sedation are well known and frequently implemented tools used to assist people in achieving a variety of objectives, such as, for example, to reduce fear or anxiety, to increase focus on a specific task, to curb an undesirable behavior, or to help control other emotions. In a traditional scenario, a therapist will work with a patient in a one on one setting to help the patient focus in order to access the patient&#39;s subconscious and provide suggestions relating to achievement of a desired goal. Ideally, the patient is able to access the benefits of the therapy once the therapy session is over, and at the time(s) when the goal is to be achieved. For example, a first patient might need help fighting the urge to have a cigarette. During therapy, suggestions are implanted that cause the patient to relate the taste of cigarettes with something bad, such that the later thought of them is less appealing. In another example, a second patient may experience high anxiety each time they visit the dentist. During therapy, suggestions are implanted to help associate the waiting room of the dentist&#39;s office with a sense of calm. However, people that seek hypnotic or related non-pharmaceutical sedation treatments (referred to herein in a non-limiting manner as “patients”) often cannot access the suggestions at the proper time, or the anxieties or impulses relating to the goal may overcome the strength of the suggestion. In these cases, patients can benefit from a more timely delivery of the suggestion, so that it is received at the time when most needed. 
     It has been recognized that therapy sessions may be pre-recorded and played back on demand. For example, U.S. Publ. No. 2013/0236865 entitled “Systems and Methods for Modifying Human Behavior Using an Audio Recording During Sleep” teaches the playback of a recorded therapy session during sleep to help reinforce the therapeutic message. However, the session is generated manually by the therapist, and cannot be modified or tailored for a specific need by the patient upon demand. U.S. Pat. No. 6,057,846 entitled “Virtual Reality Psychophysiological Conditioning Medium teaches a “virtual reality device” used to induce a state of meditation or hypnosis upon demand. But the message is still pre-determined by the therapist and not adjustable by the user. Such messages may not fit the immediate need of the patient, or may not fit the time window that the patient has available. 
     Somewhat more flexibility and user control is suggested by U.S. Pat. No. 6,565,504 entitled “Method and Apparatus to Create and Induce a Self-Created Hypnosis,” which teaches an “interactive computer device” that presents a “custom hypnosis script” to induce hypnosis and make behavioral suggestions. According to the invention, a user submits responses to pre-set questions that form gaps in an already existing or pre-assembled script, e.g., “pre-programmed textual material.” A script is assembled based on these inputs and sent back to the user. While this adds slightly more flexibility, the user is still stuck with the formal nature of the pre-set questions, and it is really the therapist that is creating the script using the responses. The length of the script or audio file is pre-established by the therapist or the program written at the request of the therapist. Patients (users) must be careful not to induce a state of hypnosis during which they will be needed to perform complex activities. If the script lasts 30 minutes, the patient must have at least that much time to dedicate to listening to the script in the prior art systems. However, a patient in a dental waiting room, for example, may have only a few minutes before their scheduled appointment. They need a quick, tailored solution available to help ease their anxiety. 
     What is needed is a software solution that provides superior flexibility to the user of the hypnosis script, and provides them a solution that does not rely on the input or control of a therapist in situations where that is not practical or possible. The patient should be able to establish the length of the script, and it can be assembled (dynamically, if necessary) to accommodate that time window. Furthermore, options and selections are needed that can allow a user to fully tailor the script to their purpose, rather than simply providing answers to pre-set questions. An improved solution would involve truly tailored inputs, e.g., where the user can provide material that can be placed within the script for compilation with other content that is then automatically assembled into a customized script for playback. 
     SUMMARY OF THE INVENTION 
     The present invention comprises a system and method for automatically compiling a personalized media file that can be used to assist in goal achievement through non-pharmaceutical sedation. According to a particular embodiment, the invention comprises a computer application that presents a user interface for allowing a user to interface with the program and set up a personally tailored script. The application may provide for audio recording, such as of the user&#39;s voice, for purposes of receiving a tailored message to be synchronized with pre-recorded material. The patient may proscribe a time window or specific time length that the script to be generated should last. Based on these and possibly other inputs, the application generates a truly tailored, suggestive script for playback by the patient at the patient&#39;s discretion. The script may then be electrically stored in a data memory for later use. 
     In another embodiment, the invention comprises a computer application that presents a user interface for allowing a user to interface with the program and set up a personally tailored script. The application may provide for submission of a sound bite captured in, for example, a .AVI file or other sort of sound file, such as a snippet of a song, a verbal message spoken in a particular tone of voice, etc. The term “snippet” is used within this disclosure to generally refer to any digitally-captured short audio sound bite, whether it be music, spoken word, any other auditory sound, or even recorded silence. As used herein, a snippet may be many seconds or even a minute long, but is often only a few seconds or even a fraction of a second in playback length. Snippets are used to create a tailored message to be synchronized in order to form a script. A snippet may be voice, music, or even a video component. It may be pre-recorded and stored in a database for use by the system, or it may be user-provided. A user snippet could be a recording of the user&#39;s voice providing a message component such as a reminder, text provided by the user and converted into a snippet by the system, or some pre-existing media file clip provided by the user and not within the system collection. 
     As used herein, the term “script” is a complete electronic media file (typically an audio file, but it may have a video component) that will be several minutes long, and is the output of the system. The patient may proscribe a time window or specific time length that the script to be generated should last. Based on these and possibly other inputs, the application generates a truly tailored suggestive script for playback by the patient at the patient&#39;s discretion. The script may then be stored in a memory for later use. 
     In still another embodiment, the invention comprises a computer application that presents a user interface for allowing a user to interface with the application to set up a self-designed script. The application solicits input from the patient by asking indirect questions about the patient&#39;s interests, goals, and other characteristics. Instead of placing direct feedback from the patient into the script, the application uses responses to the indirect questions and interprets those responses using pre-programmed analytical guidelines to select specific pre-programmed content based on the user responses. In this manner, the application automatically selects the content such that it will be best suited for (and delivered in the most suitable manner to) the patient. The content is then used to generate a truly tailored suggestive script for playback by the patient at the patient&#39;s discretion. The script may then be electronically stored in a data memory for later use. 
     In some variations of the above-described embodiments or other embodiments, the computer application may be able to dynamically adjust the length of a pre-recorded personally tailored script. For example, if the patient originally requested that the script be 8 minutes long, but now knows that they have only 4 minutes before an event is to take place, the user could request that the application trim components of the script such that it completes in 4 minutes. In this manner, the patient is not in a compromised mental state at the time when the event is to occur, but rather is alert and fortified with the script&#39;s message. 
     Thus, the invention provides a new and useful system and method for automatically assembling a tailored hypnotic or therapeutic message for use by patients at the time of (or just prior to) facing a challenge or attempting to achieve a goal. While certain embodiments are referenced above, other embodiments, systems, methods, features, and advantages of the present invention will be, or will become, apparent to one having ordinary skill in the art upon examination of the following figures and detailed description. In some cases, embodiments may incorporate one or more of the features from the above-referenced embodiments. It is intended that all such additional systems, methods, features, and advantages included within this description, be within the scope of the present invention, and be protected by the accompanying claims. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention can be better understood with reference to the following figures. 
         FIG. 1  depicts aspects of a mobile device serving as a general purpose computer for facilitating aspects of the invention. 
         FIG. 2  depicts contents of a memory component of the mobile device of  FIG. 1 . 
         FIG. 3  depicts an exemplary graphical user interface of a self sedation and suggestion system application, according to certain embodiments. 
         FIG. 4  is a flow chart showing process steps of the self sedation and suggestion system application of  FIG. 3 , according to certain embodiments. 
         FIG. 5  is a flow chart showing other process steps of the self sedation and suggestion system application of  FIG. 3 , according to certain embodiments. 
         FIG. 6  depicts a preferences screen of the self sedation and suggestion system application, according to certain embodiments. 
         FIG. 7  depicts a screen for gathering input for use in selection and delivery of indirect suggestions, according to certain embodiments of the self sedation and suggestion system application. 
         FIG. 8  depicts a first script setup screen of the self sedation and suggestion system application, according to certain embodiments. 
         FIG. 9  depicts second script setup screen of the self sedation and suggestion system application, according to certain embodiments. 
         FIG. 10  depicts a reminder recording screen used to record audio for use in a new script of the self sedation and suggestion system application of  FIG. 1 , according to certain embodiments. 
         FIG. 11  depicts a script sampling screen for validating new scripts in the self sedation and suggestion system application of  FIG. 1 , according to certain embodiments. 
         FIG. 12  depicts a script directory interface that allows users to select from among scripts that have been created by the user or the system using the invention described herein. 
         FIG. 13  depicts an interface screen of the application of  FIG. 1  showing playback, and offering the user an opportunity to extend or truncate playback from its stored length. 
     
    
    
     DETAILED DESCRIPTION 
     The description that follows describes, illustrates and exemplifies one or more particular embodiments of the present invention in accordance with its principles. This description is not provided to limit the invention to the embodiments described herein, but rather to explain and teach the principles of the invention in such a way as to enable one of ordinary skill in the art to understand these principles and, with that understanding, be able to apply to practice not only the embodiments described herein, but also other embodiments that may come to mind in accordance with these principles. The scope of the present invention is intended to cover all such embodiments that may fall within the scope of the appended claims, either literally or under the doctrine of equivalents. 
     It should be noted that in the description and drawings, like or substantially similar elements or steps may be labeled with the same reference numerals. However, sometimes these elements or steps may be labeled with differing numbers, such as, for example, in cases where such labeling facilitates a more clear description. Such labeling and drawing practices do not necessarily implicate an underlying substantive purpose. As stated above, the present specification is intended to be taken as a whole and interpreted in accordance with the principles of the present invention as taught herein and understood to one of ordinary skill in the art. 
     The present invention relates to a software application, and its associated functionality. While the invention will always require a user interface of some sort (e.g., inputs and outputs), and access to a memory and processor to operate the application and underlying system, the invention can be practiced using different hardware scenarios. For example, the application could be stored in a memory at a remote server or otherwise operate through the “cloud” in a distributed network system. In this case, the user would merely have the interface which would receive all commands and executions from a remote processor. In other scenarios, the application and all associated data in memory could be stored on a single hardware device in the possession of the user. In still other scenarios, a user could have a device, such as a mobile smartphone, that comprises the user interface, a memory, and a processor, but is in contact with a remote server that has access to additional data stored in a central memory. 
     Though the application described herein can operate in any such hardware configuration, it is explained herein as used in association with a mobile device (such as a smart phone or tablet) so that a user can access the software wherever needed. Though the invention is explained using mobile device  140  as an exemplary device, it will be understood that use of the system need not be on such a device and the specific type of device used does not limit the scope of the claimed invention. For example, the mobile device could be a smart watch, GOOGLE GLASSES, or some other such wearable device. 
     Referring to  FIG. 1 , a schematic diagram of certain aspects of a mobile device  140  is provided. This exemplary mobile device  140  includes an interactive hardware portion  204  and a computer portion  206 . The interactive hardware portion  204  can include one or more of a touch screen, a keyboard, a stylus, a joystick, a microphone and the like, which can be arranged in various manners and have different shapes without changing the spirit of the interaction of the hardware portion  204  with the computer portion  206 . The touch screen can be a liquid display crystal (LCD), display screen, a plasma screen, a light emitting diode (LED), or any other screen capable of displaying text and images. 
     The computer portion  206  includes an input/output (I/O) portion  208 , a central processing unit (CPU) portion  210  (i.e., a microprocessor), and a memory  212 . The CPU portion  210  can be any computer-processing unit from a singular microchip to extensive microchip configurations. The memory portion  212  can include, without limitation, any one or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, etc.). Moreover, the memory portion  212  may incorporate electronic, magnetic, optical, and/or other types of storage media, and can have a distributed architecture where various components are situated remote from one another, but are still accessed by CPU portion  210 . The interactive hardware portion  204  is coupled to the I/O portion  208  such that a command entered by a user or customer through the interactive hardware portion  204  will be forwarded to the I/O portion  208 , to the processor portion  210  and then to memory portion  212 . The input/output portion  208  may provide, for example, a keyboard for text input, a digital recording device for capturing music or voice input, cursors, touch screens, etc. It may also include speakers, audio ports, LCD screens, etc., for output to the user. 
     As illustrated in  FIG. 2 , a schematic diagram of the memory portion  212  of  FIG. 1  is shown. The memory portion  212  can include or store a database  314 , executable programs  300 ,  326 , and  324 , and an operating system  322 . The database  314  can store data related to prior use of the self sedation and suggestion system application  300  by a user, such as, for example, the user&#39;s username, password, preferences, saved scripts, or other data as discussed below. The executable programs include the self sedation and suggestion system application  300 , a touch screen interface application  326 , and a wireless network communication software application  324  such as a common browser like Internet Explorer. Various other executable programs may also be stored in memory  212  that are unrelated to the present invention. Verification data reader application  320  may be a sub-code segment or part of the OMS application component  318 , or may be a separate, callable application residing independently in memory  212 . 
     When the mobile device  140  is in operation, the processor  210  is configured to execute software stored within the memory  212  to communicate data to and from memory  212  and to generally control operations of mobile device  140  pursuant to the software. The self sedation and suggestion system application  300  and the operating system  322 , in whole or in part but typically the latter, are read by the processor  210 , perhaps buffered within the processor  210 , and then executed. When the hypnosis application  300  is implemented in software, it can be stored on any computer readable medium for use by or in connection with any computer related system or method. The self sedation and suggestion system application  300  can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. 
     In the context of this document, a “computer-readable medium” can be any means that can store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer readable medium can be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic), a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), and a portable compact disc read-only memory (CDROM) (optical). In another embodiment, where the self sedation and suggestion system application  300  is implemented in hardware, it can be implemented with any, or a combination of, the following technologies, which are each well known in the art: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc. 
     Before proceeding to a discussion of the function of the self sedation and suggestion system application  300 , it will be understood that the application is designed to function as a stand-alone application that does not require external network access to operate. Initially, the application  300  must be loaded onto the mobile device  140 , such as, for example, by downloading the application  300  from a network. However, once downloaded, the application can be launched and can function without remotely-accessed information. However, it will also be understood that users may access additional content, such as pre-recorded reminders, screen display (still pictures or scrolling video), background music, or full scripts, as will be further discussed below, by connecting to the cloud or to a remote server where such additional content may be acquired for use with the application  300 . 
     Turning to  FIG. 3 , a user of the mobile device  140  has elected to launch self sedation and suggestion system application  300  and has arrived at a welcome screen  150 . It will be understood that the display screens of the illustrated embodiment are non-limiting in their screen design, layout, or naming of particular options or selections. Rather, it is the functionality of the application and interaction with the user through the interface screens that defines the invention. The welcome screen may offer information or advertising such as advertising text  151 , instructions, disclaimers or warnings such as instructional text  152 , and a start or sign in execution such as sign in button  153 . Though a sign-in feature is not necessary in all embodiments, it allows the application  300  to access material specific to the user (whether present in memory  212  on device  140  or remotely via network communication from a remote server). This material is then used by the application to call upon information saved from past sessions with the user, as described below. In the illustrated embodiment, if a user has never used application  300 , they will not have a password and will be prompted for startup account information. 
       FIGS. 4 and 5  illustrate exemplary flow charts that walk through certain functional steps of operation of application  300 . Both figures start at step  10  from the sign-in screen (such as that of  FIG. 3 ).  FIG. 4  focuses on a scenario where a user opts to create a new script, while  FIG. 5  focuses on a scenario where a user selects from a pre-existing or pre-assembled script. Exemplary screen shots showing interfaces that a user might experience as they step through the application will be discussed concurrently with the flow charts. 
     From the sign in screen, the flow of  FIG. 4  moves to Step  12  where a user opts to create a new, customized script. The user already having logged in, application  300  checks to see whether the user has any pre-set preferences on file (Step  13 ). Though a user may diverge from their preferences, these are features of a script that a user typically prefers regardless of the purpose of a particular script, the time the user has available, or other aspects that may vary more frequently. If preferences exist, flow moves to Step  20  and the preferences are adopted automatically. If they do not exist, the user is prompted to enter them at Step  14 . This may launch a new screen, such as preferences screen  160  shown in  FIG. 6 . Here, preferences are entered via, for example, drop down option boxes  162  for script characteristics such as narrator voice, screen display and style. In some cases, a sample button  163  will be provided for users to help select their preferences. For example, several voices may be pre-loaded in the system application  300  and given names such as Cindy, Joanne, or Robert. Each might use a different pitch, accent, or even volume. A user may want no screen display at all, in which case they would select &lt;none&gt; as an option. However, they may want some type of calming visual effect to assist with them reaching the desired state of focused attention. Such visual effects can also be sampled, in which case the screen will temporarily change and then revert to the preference selection. 
     In the case of style, a user may opt for the system application to select the best style of script presentation, or may select a style from among pre-set options (such as, e.g., &lt;direct formal&gt;). Generally, prior art systems were designed for use by trained therapists who could analyze patient responses and make proper style selections based on those responses. If a system places that responsibility in the hands of the patient, the patient is likely not going to have the training to make the proper selection. Most users will not understand the different style possibilities and which to choose from. For example, a person might believe they like “straight talk” and being told something directly in a strict subject, predicate format. However, that may not be the style description that most conforms to their individual needs and preferences. Because the proper style varies based on several personality characteristics of the user, the present invention offers a style analysis module  171  that helps determine the proper style for delivery of the script. In other words, it removes the need for the user or patient to have professional training or understanding in neurolinguistic customization. 
     Assuming the user requests the system to select the style, the module  171  launches and produces a series of question and answer screens such as style analysis screen  170 . In the embodiment illustrated in  FIG. 7 , this screen queries a user to rate certain statements that attempt to describe facts or characteristics about the user. The answers to questions of this variety typically do not change for a given user from one situation to another. For purposes of this application, such questions are referred to as situation independent questions. The module  171  may cycle through several such screens, and statements may be presented in a pre-set order, or may be dynamically selected or formed by the module  171  based on responses to prior questions. While  FIG. 7  features statements, the style analysis module could also present questions, and could include example presentation snippets. For example, the module might ask a user to rate how favorable a particular snippet is that, when selected, plays back a short segment of a script that describes a scene in a particular manner. In this manner, the module  171  can perform an automatic sensory selection for the user. Based on the responses, the module selects a particular style most appropriate for the user and stores it in the preferences for that user. 
     Returning to  FIG. 4 , a user may save their preferences on preferences screen  160  (Step  16 ) by selecting button  165  and flow proceeds to Step  20 . If they have requested that the system select the style (Step  17 ), the system first proceeds to style analysis at Step  18 , as discussed above, and then stores the result and proceeds to Step  20 . Ordinarily, though a user may change preferences, they will not request that the system re-evaluate their style again. Accordingly, the style selection (if system selected) may be assigned a name that the user can recognize and use as a default preference selection. The selected preferences will be used by the system application  300  as inputs in generating a tailored, customized script, as discussed below. 
     At Step  20 , the system application  300  gathers information from the user about the script that is to be created. Unlike preference information, the data collected at Step  20  is likely to vary even for a particular user from one use to the next. A sample script setup screen  180  such as might be used in association with step  20  is shown in  FIG. 8 . The questions  181 ,  182  and  183  shown in  FIG. 8  are unique to the user&#39;s particular situation at that time (or at some future time and place where the user expects to be using the script being generated). It will be understood that these are merely exemplary questions, and that others relating to a unique situation could be used. These may be referred to as situation dependent questions. By answering these questions, the user provides additional inputs used by the system application to generate the personalized script. For example, say a user wants to create a script to help them deal with back pain prior to visiting with a prospective client. They are already in the proper mental state, but they want to help remove the pain from their mind to help them focus. This would be the goal they input into the system. Options might be selected such as “Pain,” “Wait Rm,” and “Relaxed” to help the application build in appropriate messages, tones, music, and other script features. 
     Next, at Step  22 , the user proceeds to script setup screen  190 . It will be understood that the setup screens such as screens  180  and  190  may vary and may be broken up into more or less input screens to accomplish the task of gathering the desired input for the application to generate the script. In the illustrated embodiment of  FIG. 9 , the application asks the user for a desired length of the script at time entry  191 . While the length may not be exactly the length of time selected, the application  300  will target this length and choose script components so as to deliver the desired message in a meaningful manner, while allowing for proper introduction and reorientation. For example, the total script playback will be within, say, a minute of the desired length. As those skilled in the art will appreciate, an effective script must generally include an introduction, a message portion, and a reorientation portion. The length and content of the introduction will depend on the experience of the user, and the time available. The general purpose of the introduction is simply to initiate the session, to provide an explanation of what is forthcoming in the script, and to provide directions for entering a proper state to receive the message and later to remove oneself from that state. For example, it might include a simple counting routine, or a more elaborate description of levels of focused attention. The introduction will also include certain triggers to help facilitate reorientation. Once the introduction is complete, the script delivers the message portion of the script, which may include sub-parts, one or more reminders and suggestions towards achieving a desired goal using different types of metaphors, and may be short or long. After the message is effectively delivered, the script concludes with a reorientation portion that helps gently bring the user back to a full state of awareness. 
     Because a script must generally have these three components, it must be of a certain length to be effective. However, as users become more accustomed to a script, or to use of the sedation and suggestion system generally, they may be able to achieve their goals with a shorter introduction, and to return to full awareness with less reorientation. On the other hand, they may wish to fill longer periods of time remaining in the desired state of focused attention. Accordingly, as described below, the length of a script may be altered by the user even after its initial creation. However, originally, a target length is selected based on factors such as the amount of time a user has available to listen to the script and the receptiveness (and experience) the user has with reaching the desired state of focused attention. 
     Also at Step  22  and on Screen  190 , a user may elect to insert “favorites” from the menu at selection box  192 . These “favorites” would be stored in a user profile, and would correspond to specific snippets, or collections of snippets that comprise a message component that the user has identified from a different script in a previous session. A user could select stop and start points in a script (using the interface shown in  FIG. 13 , for example) to identify a portion as a “favorite” and supply it a name of the user&#39;s preference. This “favorite” would then be available through Screen  9  at box  192  for automatic insertion by the system into the new script being developed. 
     Once the user has entered the desired length of their script and any favorites, Screen  190  gives a user a chance to alter their preferences. Recall that, if preferences were already loaded at Step  13 , the user would immediately move to Step  20  ( FIG. 4 ). However, for any number of reasons, the user may, in a particular instance, wish to divert from one or more of their present preferences without permanently changing them. At Step  23  of  FIG. 4 , the user gets this chance, for example, by selecting “yes” at preference buttons  194  on  FIG. 9 . If “yes” is selected, the application  300  proceeds to Step  24  ( FIG. 4 ) where changes to the present preferences are taken using a screen similar to that of  FIG. 6 . 
     Finally, at Step  25 , Screen  190  provides an opportunity for a user to insert reminders at reminder selection box  196 . Reminders are components of the message to be delivered in between the introduction and the reorientation. How they are delivered will depend on other inputs, such as, for example, the style. Reminders may be pre-existing or may be user created. They may also be pulled from reminders that the user has created and saved in the past. For example, the reminder “smoking” may comprise a pre-set message that a user has created to help them quit smoking, or may use such a reminder that the system already contained. Thus, the user either selects from a pre-existing reminder at Step  28  or opts to create a new one at Step  26 . 
       FIG. 10  depicts a reminder creation screen  410  that is used to record new reminders. Here, Application  300  has a record and playback feature that allows a user to speak a new reminder into the mobile device  140  (using, for example, and input/output microphone). The reminder is given a unique name in box  412 , and then controls  414  are manipulated to record and play back the reminder. Once the user is happy with the newly recorded reminder, it is saved and will appear as an option in the reminder selection box  196  in future uses. Notably, reminders will be recorded in a user&#39;s voice instead of the voice selected in preferences. However, because the reminder is delivered during a state of focused attention, and because a user is typically accustomed to hearing his or her own voice, this is less concerning. However, in some embodiments, Application  300  may utilize a separate module to translate the user&#39;s spoken message to text, and then convert the text back into script to be read by the selected voice. In still other embodiments, the user could provide a text string by typing the reminder in to a text box, which could then be converted to a sound file by the Application  300 . Allowing for these alternate features requires a large repository of snippet .AVI or other sound files by the recorded voice, and thus, may benefit from a remote call to a server with a larger, centralized storage capability. 
     At this point in the process of  FIG. 4 , according to the illustrated embodiment, the Application  300  has all of the inputs required to generate the customized script. Thus, at Step  30 , the Application proceeds to generate the script using the inputs. This step uses a script generation engine that compiles a media file of (or approximately of) the desired script length using a variety of snippets (mini-files) stored in, for example, database  314  of  FIG. 2  on the mobile device  140 . In some cases, the snippets may be many seconds or even several minutes long. For example, typically the beginning part of the message (the initial relaxation instructions) does not vary significantly once certain options are selected. If a user selects a standard theme and a particular voice, for example, there may be little need to vary this component of the script. However, answers to other questions and inputs in setting up the script will call for higher levels of variation where shorter snippets of a few to several seconds or less may be used. For example, a shorter snippet and a longer snippet may both convey the same message component, but one may be selected in lieu of the other so as to comply with the user&#39;s requested playback time length. As used herein, “play time” or “playback time” is the amount of time it takes for the file in question to be listened to at its intended pace. 
     The collection of snippets can be logically organized in the database  314  by the characteristics they are designed to address, such as, for example, pain or anxiety management. They may also be recorded in different ways so as to present according to the proper style for the individual user. Not only does Application  300  select voice/message snippets, background or transition music/sound snippets are also selected and synthesized together (including overlaid so that they play simultaneously) with the voice/message snippets by Application  300  at Step  30  to create the customized script. In addition, user snippets can be inserted into the script by the generation engine where appropriate. 
     Selected reminders will be inserted within the message portion of the script at effective locations based on programming directives of the Application supplied, for example, by a seasoned therapist. In this manner, critical elements of script formation are not left in the hands of the user, but yet the user has ultimate control over the messaging and the general content. The target time length of the script is also a factor in snippet selection and synthesis by the Application, so as to attain a total script length at or near the target, insuring a proper amount of introduction and reorientation. Any visual component of the script, such as those offered as a sample on  FIG. 6  and discussed above, will typically be part of a separate, looping video file that the Application will play on the screen of mobile device  140  concurrently as the audio script file is being played. Thus, there is no need to synthesize audio and video. 
     Once synthesis of the new script is complete, the user samples the script at step  32 , modifies it if necessary (such as by returning to one or more of the steps above), and saves it once satisfied.  FIG. 11  shows a sampling screen  510  where the script can be sampled, edited, and saved. Again, the screen  512  of  FIG. 11  may remain blank during play of the script, or may show a looping video file, depending on the screen display selection. In order to allow a user to form imagery in their mind based on the audio content of the script, most users will listen to scripts with their eyes closed, either from the beginning of playback or from a point somewhere into playback. 
     We have just explored use of the system application  300  to create a new, fully customized script. However, a user may want to simply use a script they have already created, or use a non-customized script that was pre-recorded for a particular issue they are experiencing and is available on database  314  (or on a remote server, available through wireless connection). Turning to  FIG. 5 , a process flow is shown where a user again starts by logging in to the system at Step  10 , but then selects to play a pre-existing script at Step  50 . In the illustrated, embodiment, the user is then provided with a topical directory to help narrow down the list of potentially appropriate script files available. An example of such a directory is shown in  FIG. 12 . Directory screen  1200  has four category options  1201  based on the goal the user seeks to achieve through use of the script. However, it will be understood that there could be more or less options, or the options could be topically divided based on other script characteristics such as, for example, date created, length, reminder content, etc. In other embodiments, the user could simply be provided with an alphabetical list in a file directory format from which they could select a particular script and begin playback. 
     At Step  52 , a user negotiates the directory to select a particular script and arrives at a screen such as playback screen  1300  of  FIG. 13 . Here, the user has selected a script with the saved name “Julie&#39;s Monday Script” appearing in the name field  1308 . Playback screen  1300  is similar to the sampling screen of  FIG. 11 , except that it offers a couple of unique capabilities. First, track bar  1302  is provided at the bottom of the screen. This track bar monitors the progress of the script as it plays back and, though not done in typical playback, allows a user to jump into a script at a certain point, such as, for example, to verify its contents at a time prior to or otherwise when not actually using the script to assist with goal achievement. In the case of actual use by a user that has reached a state of focused attention during use of the script, the track bar allows someone nearby to quickly estimate when the user will return to a full state of awareness. The application  300  may operate to maintain this track bar on screen, overriding any default “screen saver” or “screen hibernate” setting. 
     Finally, time adjustment module  1310  allows a user to dynamically adjust the set length of a pre-existing or pre-assembled script just prior to playback (Step  53 ). For example, say a pre-existing script that a user wants to hear is at a recorded length of 8 minutes. As shown in the example of  FIG. 13 , this length will be displayed when the script is loaded for playback on the playback screen  1300 . However, say the user is in a hurry, and wants to play a shortened version of the script. In this case, the user can use time adjustment module  1310  to shorten the length of the script. Alternatively, if the user wishes to experience a longer, slower version of the script, she may lengthen its playback time. 
     If playback time is altered using time adjustment module  1310 , the application  300  dynamically adjusts the script to conform more closely to the desired length at Step  54 . In a case where a shorter playback time is desired, this is done by substituting shorter snippets for longer ones, removing or reducing the length of pauses where only relaxing music is played, substituting a shorter introduction or reorientation, etc. However, certain elements of the script must remain in place to effectively and safely deliver the message and any reminders contained therein, so the time adjustment function is limited in its ability to shorten a script. For example, an 8 minutes pre-recorded script may be able to be dynamically modified to, say 6 minutes. But not to 2 minutes. In the case where a user wishes to extend playback, application  300  performs opposite types of script modification, such as, for example, adding new or longer “music pauses” or “reflection pauses” in where only relaxing music or relaxing word syllables are played, using a longer, slower introduction or reorientation snippet, etc. Though the edited length can be saved as a new script, the original pre-recorded script is unaffected by the dynamic modification of its length and playback of the modified version. Once the user has made any adjustments desired, the script is played by pressing play  1304  at step  56 . 
     In some embodiments there may be a “Reorient” button available on the screen during playback. Because of the application  300 &#39;s capability for dynamic modification of the script, the reorient button can be selected by a third party monitoring the user, such as in a case where it is required that the user return to a state of alertness quickly. In this manner, instead of simply interrupting playback abruptly, the third party can allow the Application to alter the playback during use so as to quickly move (skip) to a short but safe and practical reorientation snippet. In this case, reminders and the message may be truncated or not fully delivered, but the user will exit the script in a more fully aware and prepared state than if simply interrupted. 
     As a user spends more time operating the self sedation and suggestion system, the application  300  will become more accustomed to the user&#39;s preferences that may not be directly collected at preferences screen  160 . Information about the user may be determined inductively by such things as the user&#39;s age, sex or other demographics, the type of mobile device  140  or other computer the person uses to operate the application  300 , etc. This material may be stored in database  314  as customer profile information. In addition, the application  300  may provide an option for the user to “like” or “dislike” certain scripts or snippets that the user comes across during operation of script setup so as to help recommend material that will be more favorable to the user. This data may also be stored in association with the customer profile. 
     While it has been shown how to generate a new script and how to playback an existing script, it will be understood that the Application  300  also can allow for modifying an existing script through a combination of the above disclosure. For example, a user may start at step  50  and proceed to isolate a particular pre-existing script, but may want to, for whatever reason, change the voice reading the script. In this case, once at playback screen  1300 , the user could select the modify  1313  button. This would take the user through screens similar to those of  FIGS. 6 and 9 , but where the defaults are set to what already exists in the selected script. The user may then alter those pre-set selections (such as, for example, input a new reminder, or change out the introduction) and return to playback using the modified script. 
     Accordingly, it should now be clear how self sedation and suggestion system application  300  can be used to generate truly customized hypnotic scripts. The application does not simply mechanically include pre-recorded selections based on direct user input. Rather, it selects snippets of pre-recordings that fit an analysis of the user based on indirect questioning and analysis. It can also customize by including preferences set by the user, content and even recordings generated by the user. Any order or process descriptions or input selections in the figures should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the embodiments of the present invention in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those having ordinary skill in the art. 
     It should be emphasized that the above-described exemplary embodiments of the present invention, and particularly any “preferred” embodiments, are possible examples of implementations, merely set forth for a clear understanding of the principles of the invention. Many other variations and modifications may be made to the above-described embodiments of the invention without substantially departing from the spirit and principles of the invention. All such modifications are intended to be included herein within the scope of this disclosure and the present invention and protected by the following claims.