Patent Application
20080052083
a, b, c, are flow charts describing creation or editing of MIIs and the related AMSs and AIPs.
d, e, f, are flow charts describing activation and retrieval of AIPs linked to MII as well as accessing, editing and archiving processes or creating new MIIs during playing or streaming of audio-based information files.
a is a conceptual plan view of a mobile interactive communication system having a web based server connected to a user's computer devices, Radio and TV stations as well as mobile communication networks.
b is a front view of a mobile communication device having typical keypad wherein certain keys included in the keypad, can serve as the device input ports for the submission of control commands that are to be sent to connected servers or devices for activating a link to an AIP, managing the AIP activation during streaming or playing, activating a search for a predefined types of MIIs, or AMSs, or related links or AIPs, as well as for adding or editing or deleting MIIs, wherein the above mentioned operations are executed by authorized users or programs.
In the detailed description reference is made to the following terms:
In cases when the Audio-related Marking Signal (AMS) should NOT be embedded within the streamed/played file, but rather be created by an external source, synchronized with the onset of the MII during the streaming/playing process, then the following changes should be applied instead of stage 6 above—
An example for the processes of generating, editing and activating links to MII-related AIPs (Additional Information and Processes) utilizing AMS (Audio-related Marking Signals). The embodiments are described by the high level flow-chart diagrams of
For consistency, in general the arrows exiting on the left or right of the diamond shape conditional process in the flow description of the charts refer to “No”—negative decision, where a “YES”—positive response flows is plotted by downwards arrows. The processes flow described below with a reference to the process stages shown in
a,
3
b, and 3c, describe an example for a flow-chart where the term “user”, also includes an automated entity, such as a software program, follows the process of generating or editing an MII, linking it to relevant AIPs, marking it by an AMS, and defining the activation and authorization rules of relevant links.
The flow-chart starts with a check of the user intention—Is it creating new MII [301—Create New MII?], if “Yes”, the check continues to the user authorization to create an MII [302—Creator is authorized?] and if 301=“NO”, the system check the user intention to edit an existing MII [303—Edit an existing MII?] and again if 303=“YES” the system checks if the selected MII is editable [304—Existing MII is editable?] and the authorization of the user [305—editor is authorized to edit current MII?]. When the user's intentions are neither creating new MII nor editing an existing one, the system allows a return to an optimal original streaming/playing of the file. This is the file which the user entered the MII creation/editing flow, or other points of origin out of which the MII created/edited. In the flow charts, this is indicated at “NO” to [301, 303, 304]—[361—Continue stream/play MII containing file, played archived file or new file?], followed by optimal employment of the streamed or played file pointers—[362—Use MII pointer to locate optimal Point of start/continuing streaming/playing/archived file when back from MII revue/activation/creation/editing modes] and start/continue such streaming/playing mode—[363—Start/continue streaming/playing of files containing MIIs and AMSs]. If the answer to [361] is “NO” the system checks if the user intends to continue one of the alternative process-tracks—[364—Continue process?]. If “NO” the process ends—[390—END]. If however the answer is “YES” the system checks if the user intends to continue immediate exploration of relevant MIIs—[351—Explore now MIIs contained in files?] as described in more details later
When the user is not pre-authorized to create or to edit MII (“NO” to 302, or 305 respectively), the system checks if the required authorization is obtainable for the relevant requested task [306—Authorization is obtainable?], and if “YES” and the user decides to obtain such authorization—1307—Authorization obtained?] the actual process begins as described below ([308] onward). However, when the authorization is not or could not be obtained—[“NO” to 306 or 307 in the flow] or the MII is not editable [“NO” to 304 above] and the user entered the MII creation/editing process out of streaming/playing stage of a potentially MII containing file, or other alternative origin for MII creation/editing mode, the system directs the flow as described above [361 onward].
The actual MII creation or editing process starts once the user has the proper authorizations. When such authorizations are verified, the user has to identify the Information Items to be marked, the file containing the MIIs and the location of the relevant Information Item within the files—[308—Identify Information Item to be marked and files for MII insertion]. The next task is defining the AIPs related to the newly created/edited MII by associating the AIPs to the MIIs, defining their types, their storage sites, the links connecting to such sites and relevant authorization required to activate each AIP—[309—Define new/edited AIPs related to new/edited MII].
The next stages of the flow are AIP dependent, and in particular, aimed at adding necessary clarifications to MII-AIP combinations that are not based on simple streaming of audio content, already stored in a predefined site, which can be managed by any communicating device. When the AIP is an information item or a process created by the MII creator/editor during the process of building the MII-AIP combination—[310—AIP is created by MII creator or edited by users?] then the creator/editor should create/edit the AIP, including links to the MII, and define the limitations related to the usage, editing, or adding content to such AIP—[311—Create/edit AIPS, their links to MII, and authorizations to edit it]. If [310]=“NO” and the AIP is a search process—[312—AIP is an MII related search process?], then the MII creator should define such search parameters, including the search space, search parameters and standards for presenting search results, particularly if dependent on User's com-device's characteristics—[313—Define search term, space or engines to be used].
If [312] =“NO” and the AIP is a process of transferring data file/s (e.g., “podcasting”) from a certain storage site or streaming of data other than “pure” voice files such as, but not limited to video-streaming then [312]=“YES” continue to—[314—AIP is a transferring of data to Com-Devices?], (com-device=communication device, used for transmitting or receiving information via communication connection) and after stages [312] and [314] above, when multitude of communicating devices can potentially receive the AMS connected to the relevant MII and/or activate or receive relevant AIPs—[316—
The limitations defined in [317] are eliminated if [314] is “NO”, namely, the AIP is limited to basic audio streaming to a receiving device AND streaming is directed only to the device used for receiving the MII-containing files and activating the link to the AIP—[315—AIP is limited to single device activation/reception of audio streaming], which flow directly to the last stage in AIP analysis, as the next stage after [317], namely, checking the number of AIPs related to the created/edited MII—[318—More than a single AIP is related to MII?]. If more than a single AIP is connected to the same MII, the default one, per user's characteristics should be defined—[319—Define default link per user and linking modes to other AIPs].
Once the default link is defined or if only a single AIP is connected to the MII [“NO” at stage 318], the AIP definition can be finalized and the AMS definition process can start—[320—Finalize definition of AIPs & links, Start AMS creation]. As the AMS can be used for indicating the specific type of content included in the related AIPs or alternatively to the types of links used to connect to such AIPs or at the authorizations required to activate such links, the first check in the flow relates to the full meaning of the structured AMS—[321—AMS embeds meanings to users beyond a basic marker?]. If the answer to the last check is “NO”, the flow still checks if there is a need for a single type of AMS to point at certain MIIs—[323—MIIs creator requires single type AMS for marking all relevant MIIs?]. More than a single AMS type [“NO” to 323] may be required, for example to point at data which is not necessarily related to the types of MII, AIPs, relevant links and activation rules but rather based on other parameters related to the MII creation/editing phase such as identification of creator/editor, time of creation/editing existence of comments to original AIPs, etc. In such a case the flow allows determining of differentiators between newly created/edited MIIs and former items—[326—Define differentiators between existing and added/modified AMSs].
If, however single AMS type is sufficient, its selection, as well as the selection of the multi-type AMSs defined at [326] depends on the existence of an AMS library, available for use by the MII creator/editor and the intention of the creator/editor to select AMSs out of this library—[327—AMS library exists and open for creator/editor use?], when “YES”—[328—MII creator/editor intends to use AMSs out of library?], when “YES”—[329—Select AMS out of general purpose library items]. In both cases of not selecting the AMSs out of the library or building the AMSs independently (when library is not available—“NO” at [327], or the user prefers not to use it—“NO” at [328]) the next stage is the fine-tuning of the AMSs—[330—Create AMSs by defining their parameters:
Before going into these stages an example is shown of the flow branch when the answer to [321] above is “YES” (namely, there should be a well-defined linkage between the AMS audio-signature and one or more of the related types of MIIs, AIPs, used links and activation rules). In such a case, the first check if the linkage-type which can be either MII/AIP/Link/rules type dependent—[322—AMS is linked to common link/rules types, associated with MII/AIP?] or if [322]=“NO”, the AMS may be connected to other agreed common parameters such as MII priority, activating device related parameters, user preferences (such as language), etc—[324—AMS is linked to other common parameter?]. When [322] or [324] above are “YES” the flow continues to a check if there are agreed and set relations between the AMS type and its meaning and if the MII creator/editor intends to use such preset relations—[325—Rules connecting AMS type exist and accepted by creator/editor?]. If the answer to [325] is “NO”, the flow is switched to [327] described above and continue accordingly. If the answer to [325] is “YES”, then AMSs are constructed based on such preset of rules (It should be noted that AMSs may contain within their audio-signature several serial or overlapping components, each pointing at different meaning connecting the AMS to the content of the MIIs, AIPs, and relevant activation rules)—[331—Construct AMS per predefined library rules.], and the product of [331] flows with product of [330], described above, into the AMS insertion stages.
The first stage of AMS insertion checks if some of the AMS are intended to be embedded within the MII containing file—[332—Some AMSs are to be embedded within MIIs containing files?]. If “YES” the flow proceeds to the actual embedding of the constructed AMS within the file—[333—Install relevant AMSs within preset file based on AMS onset timing] and continue checking if other types of AMSs playing modes are to be synchronized with the MIIs. When not all the AMSs are designed for embedding within the MII containing file ([332=“NO”]), and after [333]), the flow checks if AMS-MII relations are based on retrieval of the AMS out of a storage location other than the MII-containing file and the synchronization requirements between the AMS and the corresponding MII. The first check in such a case is if some AMSs are designed to be stored external to the MII containing file yet played through the same communication channel in a synchronized manner—[334—Some AMSs are external to said file but played through same com-channel?]. If “YES” the process synchronizes the activation pointers of the files containing the two data items (MII and AMS) using the AMS triggers—[335—Synchronize AMS playing-pointer with file pointers], and continues as in the case of [334]=“NO”, to check if some AMSs are designed to be played through a different channel of the same device used for streaming/playing of the MII containing file (for example, in the case of a cellular phone, while the MII containing file is streamed through the main network channel (GSM, 3G, Wi-FI etc.), the AMS can be transmitted through external source received synchronously by the same cell phone (BlueTooth, IRDA etc.)). [336—AMSs are external and played through different Channel of same device?]. If “YES”, the process verifies the usability of such external channels, validates the synchronization of AMS onset and the streaming/playing of the MII containing file, and defines any limitations imposed on future users and their devices—[337—Verify usability & external activation of relevant channel and synchronize it with AMS onset].
In case [336=NO], and after [337] the last alternative for AMS insertion, playing the AMS by devices other than the once used to receive the MII, is checked—[338—Some AMSs are played by devices which are not used for receiving MIIs?]. If [338=YES], then the insertion process verifies the online control over the relevant AMS playing devices for synchronizing them with the MII playing devices—[339—Online control relevant devices, for synchronizing with MII containing file]. It should be noted that in all cases when AMS is transferred to the relevant device in the form of an AMS trigger, namely the AMS is not embedded in full in MII-containing file, then the device used to activate the AMS can either filter certain AMSs based on their meaning or customize them if so designed by the device user. If [338=NO] and after [339], the next stage, relevant for all types of AMS insertion procedures, is defining the activation and authorization rules for each AMS-MII combination, including, but not limited to, the following examples i) masking rules imposed on certain non-authorized users, as well as masking rules requested by authorized users for minimizing the number and types of AMS-MII combinations transmitted, by preventing the masked users from hearing certain AMSs, or ii) the necessary logic required for responding to an AMS when either the activating device or the planned AIP receiving device are not necessarily the devices used to receive the MII, or iii) the authorizations rules defining which of the users can activate each AIP, once exposed to AMSs, under what terms and if not preauthorized, can authorization be obtained—[340—Define activation and authorization rules].
Once the AMS-MII coupling is done, the creator/editor can save the results for future use or search. If there is an existing MII archive or the user elects to start building a new MII archive—[341—Use existing or create new MII archive?], then the relations between the newly created/edited MII, its related AIPs, AMS and relevant activation and authorization rules are stored within such structured archive for achieving simplified “search & find” for any of the stored data components and personalized processes by a future user—[342—Archive MII data together with related AIPs, associated links, AMS & activation rules]. If an archive is not existent or cannot be used, the user can still save all newly-created relevant parameters and the relations between them, for example as suffixes of the MII containing file—[343—No archive available. Save MII/AIP/AMS/activation and authorization rules combination for later use].
Once the newly created/edited MII with all its related AIPs, AMSs links and activation rules are saved either utilizing an archive [342] or on a provisional basis [343] the flow lets the MII creator/editor select between continue with MII creation/editing and going back to streaming/playing of data which became the origin of the MII creation/editing. When [344—create/edit new MII?]=YES, the process is switched back to [301] described above, if [344=NO], the user is switched to an optimal point at the MII containing file from which the process started through—[361 to 363], or it allows the MII creator/editor to continue with MIIs related tasks—[363 to 352 as described above], or to END the process—[361 to 390].
The processes of activating MII related links in response to hearing an AMS with an intention to reach related AIPs is described in the branches of the flow presented in
It should be noted, however, that the need for well-defined relations between different user devices is case-sensitive, and under certain circumstances it is not required at all. For example, MII-containing information can be broadcasted or multi-casted to specific user groups over channels such as digital or analogue radio or TV, through the Internet over governmental data distribution channels, or through local Audio or Audio-Visual transmission to certain user-groups within a geographically-defined area or network-defined grouping such as stadiums, schools, theaters, shopping malls, campuses, disaster areas, work-groups, participants of certain events, etc. In such a case, the user can receive the MII-AMS combination through the utilized receiving devices (e.g., radio, TV, local audio-transmission system), and respond by using communication devices such as, but not limited to, mobile or land-line phones.
The system, being responsible for transmitting the MII-AMS containing information, receives the user's link activation commands generated as a response to the transmitted MII-AMS combination. Based on the processes defined by the AIPs, the system may respond to each such activation command by transferring the relevant AIPs to the link-activating user on the mere basis of temporal correlation between the broadcasted/multi-casted MII & AMS, and the received activation message. Alternatively, if such temporal correlation is not sufficient for identifying the MII or AIP, the activation command can be expanded to include more data for identifying the MII or the AIP. Examples for such expansion are audio-trace of either the AMS, or the MII, or a combination of both included in the activation command, a specific destination to which the activation command is sent in response to hearing the AMS, a system-generated dialogue with the activation message sender for optimizing the personalized service, or a combination of the above means. Relevant AIPs can then be linked to the user either over the open communication link generated between the calling device and the relevant communication server, or between such server and a different receiving device (other than the one used for link activation purposes), if such device was predefined by the link activating user.
As an example, the system can broadcast a song or Audio/video (MII) clip, such as but not limited to, a news item, at certain timing via defined radio/TV channel and attach to the broadcasted item an AMS at certain timing during the streaming. The AMS is recognized by the listeners as an invitation for submitting activation command for transferring the full audio or audio-visual content to targeted receiving devices, enabling personal replay of such content and connection to related expanded data. The submission of the activation command triggers a process during which the server receiving the command identifies the required AIP through temporal correlation between the command and the MII broadcasting time and then it checks user's authorization for receiving the requested AIP. Such authorization can be automatically approved if the user is, for example, a pre-registered subscriber to a certain service or it can be obtained online if the user wishes and is allowed to obtain or “purchase” it through a “one-time” or permanent subscription basis, or it can be blocked if the user does not fit a certain profile as required by the MII-AMS combination creator or broadcaster (such as for example user age-group). Once the authorization is obtained the server activates a connection between the user and the AIP. As the entire process-flow as described below is conducted whenever an AMS is transmitted and a user responds, within a given time-frame, by an activation command, such system can reach a very high resolution in managing the economy and authorized distribution of requested content items by users. Yet, it is extremely simple to operate by all types of potential users, and in particular mobile-users, to a level that submitting an activation request can be as short as pressing a single “short-dial” key when the user ID is recognized and/or automatically pre-authorized by the system.
Therefore the first stage in the activation flow is selecting the proper communicating devices, matching the requirements enabling the user to be authorized by the system for AIP activation and for being connected to the relevant data sources—[350—Select applicable com-devices, define and submit user parameters and start streaming/playing of MII containing file]. Once the devices are selected and personalization completed (when required), the user may elect to use MIIs through three major alternative tracks—the first is exploring existing MIIs within certain files, using archived data without necessarily stream/play the entire MII containing file; the second is based on streaming/playing the MII containing files and responding to relevant AMSs online; and the third, which was described above in
The description below presents the first and second tracks and their optional interaction with the third track described above. The first check of the flow is focused on the user MII related intentions—[351—Explore MIIs contained in files?]. A “YES” answer to that check means that the flow is in the first or second tracks defined above and in response, the user is required to select between archive-added selections by YES to [352—Need archived data assistance?] or direct streaming/playing of the MII containing files, by NO to [352]. If [352=YES], the user sends an activation command to stream all archived relevant MII-AMS combinations contained in the investigated files—[353—Send control command to Data-base for streaming MIIs-AMSs combinations per set order]. Such a command can be interpreted by the system in several ways but the most intuitive system response is streaming/playing of all such combinations cyclically, starting from the last-heard AMS or the first AMS in the file if no streaming/playing occurred prior to receiving the command. In certain cases the user can also request the play of the MIIs excluding the attached AMSs when, for example, the meaning of AMS-type can be ignored. The simple meaning [352]=NO, which is the most probable default case of the second track, when a user passively listens to any type of MII containing files, is switching the process to [356—Listen to MII-AMS combinations in relevant files, as streamed/played by system].
Accordingly, [356] is operated by both the first and second tracks for listening to the product of the activation command. Knowing that MII-AMS exploration is intended for either selection of a specific MII for the purpose of activating related links to AIPs or adding/editing specific MIIs, or for saving relevant combinations for a later use, the current track is split into the relevant options according to the following flows: The system constantly checks if the user is still interested in MII dedicated exploration—[357—continue search for MIIs & related AIPs OR continue file streaming/playing?]. A “YES” to [357] keeps the system waiting for selection of specific MII as described below (in most standard cases the default status of stage [356]). A “NO” to [357], for example in a form of a certain activation command while being at [356], can split the flow into the alternative track and the system checks if the user wishes to save all presented MII-AMS combination for a later use—[354—Save relevant MIIs for later use?]. If “YES” the system saves the relevant combinations in response to the user command and continue [355—Save & Continue] as in response to [354]=“NO”. The next stage checks if the user intends to add/edit certain MIIs related to the presented combinations—[300—Interested in editing-existing/adding-new MII?]. A “YES” to [300] sends the process to MII creation/editing flow described above and starting with [301] at
A “YES” to [357] starts a process of further investigating the MII-AMS combinations. If the command control for streaming/playing the combinations out of a database already screens a specific group of MIIs (due, for example, to preset personalization parameters), the next check is if it is sufficient for selecting specific links to AIPs. Therefore if the check—[358—screen only specific Sub-group of MIIs, through specific MII-AMS combinations?] is YES, the user can decide if the activation of the AMS is sufficient to select a specific AIP using the check—[360—Activated AMS is sufficient to select MII-Related AIPs?] and continue the connection process as described later. If the answer to [358] is “NO”, the system checks if the user requires more data to select a specific AIP—[359—Require more data to select AIPs?]. If “YES” and MII archive or alternative storage site contains short description of the AIPs—[365—MII archive contains description of AIPs?], the user can activate, by a control command, the file containing the short description which is either streamed (if stored on remote server) or played (if transferred to user's device memory) as a preview, prior to activating the link to the relevant AIPs—[368—Activate link to AIPs short description in archive] and if such description helps to select AIP for activation and the user decides to connect such AIP it merges with [360=YES] to check—[367—connect to AIPs marked by current AMS?]. If the user responds positively (YES to [367]) by sending an activation command in correlation with the onset of the relevant AMS—[369—Activate link to AIP by sending command out of device I/O ports], the system needs to clarify the expected track of the requested AIP. If the devices planned for activating and/or receiving the AIP are not identical to the one used for streaming/playing the MII-containing file—[370—devices planned for AIPs are NOT identical to devices receiving the related MII?]=YES, the system should check if the recognition and/or synchronization and/or expected role of all relevant devices is mandatory for the process—[372—Recognition and/or synchronization of all devices are mandatory for proper Data transfer]. If such demand is not mandatory [372=“NO”], the system will connect the AIP to the activating device unless other device was clearly define as the AIP receiving channel—[373—AIP will be targeted to the AIP activating device].
If the answer [370]=“NO” (namely, a single device is used for the entire process), the system will define the MII-receiving device as the AIP target—[371—AIP will be targeted to the MII receiving device]. When [372]=“YES”, the system checks if devices' definitions and/or synchronization are OK—[374—Devices recognition, synchronization and process are OK?]. If such definition is not complete, ([374]=NO), user should finalize it prior to connecting AIP—[375—Recognize and/or synchronize and define roles of all relevant devices]. If however [374]=“YES”, The AIP will be targeted to the receiving device as defined by the user, in response to recognizing the activating device and correlating it to the relevant MII—[376—AIPs will be targeted to device in correlation with link activator specs].
Going back to the branch where the answer to [358] is “YES” or the answer to [359] is “NO” or to [365] is “NO” and—[360]=“YES” the process flows to [367] as described above. If however [360=“NO”] the process flows to [361] onward as described above. If [367] above is “NO” the process flows to [351] as described above, enabling the user to reconsider its next MII explorations.
Once a user sent an activation command for an AIP ([369] above), and the system verifies the device to which such AIP should be targeted at or connected to [371, 373, and 376 above], the system continues with checking user's authorization to activate the requested link—[377—User activation is authorized and AIP receiving device is identified?]. If “YES” the system connects the user's at least one device to the relevant AIP—[378—Receive requested AIP by targeted receiving device] and the user can listen to, watch and listen to, or activate processes presented by the streamed/played AIP—[379—Listen to relevant information or activate relevant processes]. If [377]=“NO”, and authorization is obtainable—[380—Authorization is obtainable?] and the user managed to obtain such authorization—[381—Authorization obtained?], and the planned AIP receiving device is OK—[382—AIP receiving device is found OK?] or if [382=“NO”], and an alternative device is defined and recognized by the system—[383—Alternative user device recognized?], the process flows to [378] and continues as described above. If, however, authorization cannot be obtained or user did not manage to obtain it, or no receiving device is connectable—(all of [380], [381], and [383]=“NO”), the process flows to [352] and continues as described above.
At any point of being connected to the AIP the user can terminate the link and the system can do it automatically when connection-time or user-authorization is over, or when communication link fails—[384—User or system Interrupt link to AIP?]. If such termination occurs the user can decide between trying to reconnect the link—[385—User tries to reconnect?] and if “YES” the user sends reconnect command [386—Send reconnect command] and the process flows back to [377] above. If however [385=“NO”] the flow is directed to [361] where the user can select between continuing streaming or playing of the MII-containing files, exploring MIIs (through [364] to [351] and flow as described before) or ending the entire process through [364] and [390—END].
In another embodiment of the present invention the construction of an optimal AMS depends on different parameters, to be analyzed during the MII creation process. Such parameters can include, among others and without losing generality, the characteristics of the expected MIIs user-base, the types of the created MII and the files containing such MII, the diversity of available AIPs related to each MII and the restrictions related to or authorizations required for activating the links to such AIPs. For example, it can be expected that when the created MIIs are built for a personal use by the MII creator, then personal preferences may dominate the AMS construction process, while a creator of MIIs, to be used by the general public, may wish to construct the AMSs utilizing AMS library, when applicable, which accumulates the accepted and agreed relations between the AMSs components characteristics and related types of MIIs, AIPs and associated links or activation rules.
Further examples for optimizing the attached AMS audio-signature to its MII is done by taking into account the audio background signals of the containing file, the variance of different MIIs contained in the same file, and the preset personalization by the file recipient. Such considerations may cause, for example, selection of different types of AMSs to be embedded in different types of MII-containing files, such as “free speech discussion”, “reading out of text-books or encyclopedias”, “audio-guidance”, “musical pieces”, etc. Furthermore, such considerations may be optimized, without limiting the generality of the method, for: 1) automatic marking of similar types of MII such as auto/manual recognition of a speaker and allocation of a predefined AMS to that audio-source; 2) automatic/manual marking of high-priority content, or content related to specific category, as defined by the MII creator, or editor, or by the MII recipient, through personalization, with specific predefined AMS tagging, enabling fast automated or manual search processes within the containing files; 3) Linking the AMS type or even the actual onset of an AMS to the recipient authorizations for activating the AIPs related to the MII marked by that AMS, 4) Selecting the AMSs for each MII per predefined preference list personalized by the user, and utilized for coupling the AMSs to MIIs upon building the data file for streaming or playing by a specific user, or storing by a user at a personalized storing site. 3) and 4) above are easily manageable using the AMS trigger technique, where the user device can be programmed to filter or customize per user preferences specific MII-AMS combinations.
Thus if a recipient is not positively identified as an authorized user of the related AIP, or if the user selected not to activate the method in relations with specific types of MIIs or specific types of APIs, the AMS can be automatically deactivated for masking the existence of the related AIP, or, alternatively, when authorization is obtainable, the AMS audio-signature can include a component, indicating that user authorization should be obtained prior to activating the AIP. However, when an authorization is obtained (for example by an online password insertion, or commitment to pay usage fees, etc.), the AMS is reactivated or modified (audio-signature-wise) for enabling access to the AIPs.
AMSs in general, and AMSs having full or partial temporal overlap with the MII in particular, may be based on incorporation of certain word enhancement effects, change of intonations, background tunes, overlapping vibrations and/or modulated visual signals (such as flashing light). AMSs design can be very simple such as a single audio frequency at constant amplitude and fixed duration. On the other hand, AMSs can be designed to present the flexibility required to reflect personal preferences, such as preferred music adapted to certain timing and mood of the person accessing the AMS, or to indicate the specific types of their MII, AIP and the links between them, using one or several building blocks (components) taken from audio based effects library, or created by the MII creator or editor for personal/public use.
An example for a very basic and simple AMS is a short (less than 300 ms) single-frequency audio signal (“bip” at the peak sensitivity of audible-frequency, e.g., the 1-2 KHz range) having moderately balanced amplitude in the range of comfortably acceptable decibels level vs the MII audio level, wherein the AMS is activated, for example less than 1 second before the beginning, or less than 1 second after the end of streaming/playing the related MII. In such a simple case, an AMS recipient should only be notified in advance, for avoidance of ambiguity, about expected temporal relations between the onset of the AMS, its related MII and the activation command of the relevant links to AIPs or the commands required to return from such linked sites to the original streamed/played file.
A more complex type of an AMS can be, for example, without limiting the generality of an AMS structure, a signal based on combination of multiple audio or audio-visual or audio sensual components where the first and earliest occur prior to the onset of the MII, used for alerting the recipient, regarding the type of the forthcoming MII and the existence of identified accessible AIPs, wherein the second component is overlapping or partially overlapping the MII, indicating the type of the related AIPs, and the last component occurs after the second and indicates the type and number of related links, as well as other data, related to such links. Such related data may comprise of link activation costs and authorization requirements, networking bandwidth requirements, size of linked information file, language of content, security requirements and other parameters required ahead of link activation.
In another embodiment of the present invention, the systematic linkage between the audio-signature of single or multi-component AMSs and their relations with types of relevant MIIs, AIPs, associated links and activation rules, is used for enabling new methods for content-based fast-search for data. Such a search utilizes search-key elements that are either related to the said audio-signature or to the types of MIIs, AIPs, relevant links or relevant rules, all of which can be either personalized by a user or accepted by a group of users, employing common rules for selecting AMSs audio-signatures. Two major search modes can be based on the methods described herein. The first search mode relies on direct scanning of the files containing the MIIs in search of proper fit between the search-keys, translated into audio-signature and certain characteristic of the AMSs related to the scanned files. The second mode can be based on searching for attached digital files characterizing the AMSs, MIIs and AIPs designed to be easily accessed and analyzed by automatic search machines. Thus the second search mode usually relies on searching of an archive/built or used (if formerly established by others) by MII creators for archiving the entire chain of relations connecting MIIs, their content, their location within certain files, the storage address of the containing files, attached AMSs related AIPs through associated links, an agreed library of AMSs and AMS' component types, and set activation rules.
The activation of either one or both AMS-based search-modes can be as simple as a prompt extraction of all the MIIs included in a given set of audio-related files, by submitting an activation control command, out of the receiving-device input ports. In response, the system reacts by playing and/or saving the relevant MIIs-AMSs combination according to a preset order such as “AMS timing after file start-point” or “Grouping by AMS-type followed by internal ordering according to a the time-stamp of the MIIs within preordered groups of files”. The MIIs in the archive file may also be selected to be heard by the user without their related AMS but knowing that related data embedded in the AMS audio-signature may not be available when considering AIP selection.
A more complex AMS-based search, either preset or customized online, enables smart screening of the MIIs according to search-keys that are embedded in either single or a group of parameters such as AMSs types, certain components constructing the AMSs reflecting MII types, AIPs types, MII generation process history, AIPs types, activation rules and limitations, including but not limited to technological requirements, authorization rules and activation economical parameters, MII creator priorities, recipient predefined priorities, and advanced default rules for search-key combinations which are preset in advance.
In another embodiment of the current invention the default AIP linked to a certain MII is selected based on the characteristics or preferences of the recipient of the MII containing files, so that a different recipient may be connected to a different default AIP upon activating the links marked by the same AMS. The reasons for correlating the default links with the identification of the recipient can vary from user preferences (e.g. language or fields of interests) or MII creator preferences (namely, the links that the creator would like to expose to a certain user) to pre-approved authorizations or online obtained authorizations, dependent on the user ID. In an example of the versatility of the AIP use, different users responding to the same AMS will activate AIPs relating to specific MII, such as, but not limited to, detailed advertisement data generated by the MII creator/editor, adapted to the users' profiles.
The control commands generated by a user or program can be based on the existing I/O ports of the device used for activating a link to an AIP or to send any other control command to the system while, before, or after receiving information. The methods included in the current invention enable using a single port, such as a single key included within a device key-pad to generate a control command for execution of system operation. More complicated commands can be based on the usage of more than single port (e.g., more than single key) to construct a command wherein such ports can be activated either serially or in parallel, utilizing existing features of the communication devices, and allowing either DTMF or IVR or internet-based or a combination of the above for linking the user or program with the server. Alternatively, when a software agent is imported and installed on the communication device, the generation of a control command is managed using said software agent which can enable personalized simplified links between each user and the system. The resulted control commands can be based either on an accepted set of rules used by all MII creators, editors and users or alternatively can be personalized by an MII creator or editor upon building new sets of MIIs and related AMSs, AIPs and activation rules.
a describes an example of a mobile interactive communication system having a communication server 450 connected to users through their mobile devices such as 460, utilizing applicable wireless networks, such as 461 through 451, 452, and through computerized devices 462 via applicable networks such as the Internet network 463, also connected to the Radio and TV stations 453. The figure is applicable to both system architectures, including i) a centralized operation of the system in which server 450 controls the entire operation, and the user devices, such as 460 are used only as means to submit activation messages, and if authorized and qualified receive some of the AIPs, and ii) a distributed architecture in which the user device 460 can be a part of a distributed server functionalities such as for example be used to monitor authorizations or even monitor and filter out specific MII-AMS combinations when the device itself is used to receive the MII containing files, or even manage a local archive.
Users receive information streams via broadcast information over the air 464 by antenna 455 of using devices such as for example car radios 454 or other type of receivers such as TV or mobile devices 460. The mobile device 460 may receive the information from the mobile station 451 via the mobile communication system 452 using the mobile wireless spectrum schematically marked by 461, or via dedicated radio/TV spectrum directly from station 453, or via the Internet connected to the device utilizing the mobile wireless spectrum or other wireless spectra such as Wifi, WiMax or others.
In the example of
Upon decoding the activation commands submitted by the user while activating the interactive session or during the interactive dialogue between the user and the server, the communication server 450, may start a process, based for example on the activation commands' timing, together with the decoded data embedded in the activation messages, the user ID and predefined preferences which could be set by the user prior to using the system. Other correlation techniques can be used to match the user and the requested AIP. Such techniques may comprise the use of one or more of a) the user's selected communication channel for sending the activation command, b) the location when responding to AMS, based on such as routing information, embedded GPS information, correlation with the Cellular cell used by the user or the source of the user's upstream in the case where the user response via its CATV or IPTV or telecom networks c) a portion of the AMS, transmitted as part of the activation message, d) a portion of the MII, transmitted as part of the activation message, e) a portion of the file containing the MII, transmitted as part of the activation message.
From the example given in
Without limiting the generality of the described method,
In one implementation of the current invention, activation commands are assigned to the device input ports. The following is only one example of the functions which can be implemented utilizing a standard keypad of a basic mobile communication device as described schematically by
In the current example the device keyboard of
According to one embodiment of the current invention, the user may use the I/O ports of the mobile communication device as a hand held “remote controller” to interactively manage the information flow and to activate related linked processes. The interactive control is described in details by the following step-by-step operation processes, used for search for, find and activate links to MII within an audio/audiovisual information file:
Adding online user-created AIPs to an audio-based file:
For example, editing or deleting existing MIIs and their related links out of an MII-containing file or a related archive may be conducted as follow:
For example, locating and activating an archived MII and its related links and AIPs may be conducted as follow:
An example of activating a process of connecting to communication network nodes:
In a different embodiment of the current invention, the methods for audio-marking of information items (MIIs) for identifying and activating links to additional information or processes (AIPs) related to the marked items can be applied to expanding existing current art IVR (Interactive Voice Response) based systems while avoiding a direct change of the internal architecture of an existing IVR menu-tree architecture. The current IVR based systems are commonly designed with hierarchical multi-level, menu-tree architecture in which users usually access the menu-tree through its top level and by selected the optimal option at each branching junction, they move between the menu-levels until reaching the required information or process they search for.
According to the current invention, the current art IVR menu-tree architecture can be expanded through marking specific information items (MIIs) by AMSs and enabling connection to related AIPs, thus allowing retrieval of additional linked information or processes from alternatively-linked sources, or generating short-cuts between branching junctions of the existing menu-tree, while avoiding changes of the existing IVR tree logic. Furthermore, since the insertions of MIIs together with related AMSs, AIPs, and relevant activation rules are based on authorization rules, defined by the MIIs creators or editors, the IVR architecture can be easily personalized for specific users or user-groups without any change of the common basic logic of the IVR-processes. Thus, the expanded version of the original, PRE-CHANGED IVR logic can present personalized short-cuts of the common menu-tree or introduction of new information items or processes that are relevant for a restricted group of users only.
The common architecture of a standard menu-tree restricts the number of links between lower-level branches of the tree connected to different main branches. Thus, for example, if a user decides to re-select a major branch other then one selected at [511], the system must receive a “go-back” command and the “back” options usually consist of limited alternatives such as: “back to the former junction point”, “back to the top of the menu” or “back to a ‘help’ junction”. In our case, for example, a user at [539] wishing to move to, for example, the [54X] level of the tree needs to go back twice (from [539] to [523] and then to [511]), or if applicable jump by a single command back to [511] and then starts the process again by three successive selection commands. Such logic, even though enabling a guided direction of a user to any information item required, may be found extremely tedious when the user needs to go through many branching points in search for the required information.
The other modules included in
A user, while being at certain IVR-level, [511] in this case, hearing the guideline to select between the next level options, can hear an AMS, related to a certain MII-1, enabling prompt linking by an activation command (“#” according to
A user, while selecting relevant options at [511], reaches [521] since the common logic requires the user to be preauthorized for entering main branch [522]. Under certain circumstances the required authorization for using [522] is obtainable but users should be exposed to the relevant data. By adding the relevant details while introducing [521] and marking certain authorization request as MII-2, the user can select relevant link, presented as AIP-2 at [561] using relevant activation command (“#” according to
A user authorized to enter branch [522] selects an option [534] to hear that not all of options [54X] are available for activation, but further clarification can be retrieved through AIP-3 connected to MII-3 presented by AMS-3. By activating AIP-3 at [571], (using “#” according to
All the above examples include an option, during activation of the relevant AIPs, of sending the “back” control command, leading eventually to a return to the original IVR branching point within which the relevant MII was marked and the relevant AIPs were activated, enabling smooth return to operating the original IVR logic.
Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.
This application claims priority from U.S. provisional application No. 60/823,741, filed Aug. 28, 2006.
| Number | Date | Country | |
|---|---|---|---|
| 60823741 | Aug 2006 | US |
