Patent Publication Number: US-10326716-B2

Title: Information processing device and information management device

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is based on and claims priority under 35 USC 119 from Japanese Patent Application No. 2016-173140 filed Sep. 5, 2016. 
     BACKGROUND 
     The present invention relates to an information processing device and an information management device. 
     SUMMARY 
     According to an aspect of the invention, there is provided an information processing device including a communication unit that, if the order and time interval of an operation performed on a first device representing the information processing device, and an operation performed on a second device representing another information processing device match at least one predetermined pattern representing a predetermined order and a predetermined time interval, performs a communication associated with the predetermined pattern between the first device and the second device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Exemplary embodiments of the present invention will be described in detail based on the following figures, wherein: 
         FIG. 1  schematically illustrates inputs made on multiple devices; 
         FIG. 2  is a graph illustrating the degree of variability with changing speed of rhythm; 
         FIG. 3  is a graph illustrating the results of regression analysis for rhythm ABA; 
         FIG. 4  schematically illustrates rhythm ABA-C; 
         FIG. 5  illustrates the frequency of error detection for each rhythm; 
         FIG. 6  illustrates a system configuration according to a first exemplary embodiment; 
         FIG. 7  illustrates an event table; 
         FIG. 8  schematically illustrates rhythm ABAB; 
         FIG. 9  illustrates the results of regression analysis of L 2 , L 3 , and L 4  for each rhythm; 
         FIG. 10  schematically illustrates rhythm AB-C; 
         FIG. 11  illustrates a process performed after rhythm detection; 
         FIG. 12  illustrates a command table; 
         FIG. 13  illustrates a system configuration according to a second exemplary embodiment; 
         FIG. 14  illustrates an event message; 
         FIG. 15  is a sequence diagram according to the second exemplary embodiment; 
         FIG. 16  schematically illustrates rhythm ABA-C; 
         FIG. 17  illustrates an event table; 
         FIG. 18  schematically illustrates rhythm ABAB; and 
         FIG. 19  illustrates an event message. 
     
    
    
     DETAILED DESCRIPTION 
     Hereinafter, exemplary embodiments of the present invention will be described with reference to the drawings. 
     Basic Principle 
     First, the basic principle on which the exemplary embodiments are based will be described. 
       FIG. 1  is a sequence diagram illustrating the basic principle on which the exemplary embodiments are based.  FIG. 1  assumes the presence of device A and device B as multiple information processing devices (such as data communication devices), and illustrates that operations (inputs) according to a predetermined pattern have been performed between device A and device B. 
     This corresponds to a pattern that begins with input T 1  as an operation performed on device A, followed by input T 2  as an operation performed on device B after a lapse of time L 1 , and then followed by input T 3  performed on device A after a lapse of time L 2 . Examples of inputs T 1 , T 2 , and T 3  include actions such as tapping a touch panel or depressing a button on device A and device B. The exemplary embodiments permit data to be transmitted and received between device A and device B by use of the following repetition of inputs mentioned above:
 
 T   1   →T   2   →T   3 .
 
     In the exemplary embodiments, a periodic repetition of inputs will be referred to as “rhythmical input”. Assuming that each input is a tap, it can be said that a rhythmical tap action is used to permit transmission and reception of data between device A and device B. The advantage of permitting transmission and reception of data through a rhythmical input is described below. 
     That is, it is relatively easy for one to beat out a rhythm alone, and thus this facilitates specifying of data transmission and reception. Beating out a rhythm with others is difficult, and thus this makes it possible to prevent erroneous operation or eavesdropping. Further, beating out a long rhythm is difficult, and thus it is possible to adjust the level of security by adjusting the length of a rhythm. As long as there is a leader (conductor), and one has an intention to act with the other party in a coordinated fashion, then it is possible to beat out a rhythm with the other party, thus enabling simultaneous distribution, that is, 1-to-N data transmission. This involves a body movement such as a tap, thus allowing for easy recognition of who is transmitting data to what device from what device, which facilitates coordinated action. Furthermore, the existence of a wide variety of rhythms, such as triplet rhythms, quadruplet rhythms, ABA, A-BA, and A-AB provides a potential for expansion. 
     The present inventors have conducted an experiment about multiple rhythms. The experiment is summarized as follows. 
     Participants: 15 persons (13 males and 2 females) 
     Age: 22 to 26 (average age: 23.8) 
     Dominant hand: 14 right-handed persons and 1 left-handed person 
     Task: subjective evaluation based on four criteria conducted for 99 rhythmical taps performed with left and right hands (on a five-point scale from one to five, with one being the most difficult and five being the least difficult) 
     Ease of tap at specified speed (one tap: 150 ms) 
     Ease of tap at high speed 
     Ease of remembering 
     Ease of getting used to (ease of familiarization) 
     Eight rhythms that are ranked high in overall evaluation based on the sum of mean points for the four criteria mentioned above are selected. Further, three more rhythms are selected for evaluation by taking into account a balance in terms of their length and the number of taps with the dominant hand. The total of 11 rhythms thus selected are as follows.
     (1) ABA   (2) AAB   (3) ABB   (4) ABAB   (5) AB-A   (6) AB-B   (7) AB-C   (8) ABABA   (9) ABA-A   (10) ABA-C   (11) AB-AB   

     Now, “A” represents a tap with the dominant hand, “B” represents a tap with the non-dominant hand, “C” represents a tap with both hands, and “-” indicates the presence of a certain pause period between successive taps. For example, “AB-B” represents a rhythm that begins with a tap with the dominant hand, followed by a tap with the non-dominant hand, and then followed by a tap with the non-dominant hand after a certain pause period. A log of a minimum of five taps performed for each rhythm is collected. Further, a log is collected for each of the following cases.
     (1) When beginning the rhythm with the dominant hand (Regular)   (2) When beginning the rhythm with the non-dominant hand (Reverse)   

     Further, a log of taps performed at the following four levels of speeds is collected.
     (1) Preferred speed (Preferred)   (2) Slowly (Slow)   (3) As fast as possible (Fast)   (4) Specified speed (Specified)   

     These rhythms can be roughly classified into three-part rhythms, four-part rhythms, and a five-part rhythm. 
     The three-part rhythms include the following rhythms. 
     ABA 
     AAB 
     ABB 
     AB-A 
     AB-B 
     AB-C 
     Letting A be a first input, and B be a second input, ABA can be expressed as a rhythm beginning with the first input, followed by the second input, and then followed by the first input. AB-A can be expressed as a rhythm beginning with the first input, followed by the second input, and then followed by the first input performed after a relatively long period of time. AB-C can be expressed as a rhythm beginning with the first input, followed by the second input, and then followed by the first input and the second input that are performed after a relatively long period of time. The term “relatively long period of time” refers to the above-mentioned pause period, and means that this interval of time is long relative to the interval of time between the first input at the beginning of the rhythm and the second input that follows. Other examples of rhythms made up of three or more parts may include AA-B and AA-C. 
     The four-part rhythms include the following rhythms. 
     ABAB 
     ABA-A 
     ABA-C 
     AB-AB 
     Now, similarly as above, letting A be a first input, and B be a second input, ABAB can be expressed as a rhythm beginning with the first input, followed by the second input, followed by the first input, and then followed by the second input. ABA-C can be expressed as a rhythm beginning with the first input, followed by the second input, followed by the first input, and then followed by the first input and the second input that are performed after a relatively long period of time. AB-AB can be expressed as a rhythm beginning with the first input, followed by the second input, followed by the first input performed after a relatively long period of time, which is then followed by the second input. 
     The five-part rhythm is ABABA. Now, similarly as above, letting A be a first input, and B be a second input, ABABA can be expressed as a rhythm beginning with the first input, followed by the second input, followed by the first input, followed by the second input, and then followed by the first input. 
       FIGS. 2 and 3  illustrate the results of the experiment.  FIG. 2  illustrates the length of a tap period for “Regular” and “Reverse”, for each of the four levels of speeds: Fast, Specified, Preferred, and Slow. The length of the tap period for each level of speed is as follows. 
     Fast: 115.4 ms 
     Specified: 139.2 ms 
     Preferred: 217.1 ms 
     Slow: 391.6 ms 
     The above results indicate that the resulting rhythm does not change much between when started with the dominant hand and when started with the non-dominant hand. It can be appreciated, however, that greater temporal variations are observed for “Fast” and “Slow” than for “Specified”. 
     For any two taps of interest, if the time difference between the two taps is equal to or less than 46.3 ms, then the two taps can be regarded as being performed simultaneously, whereas if the time difference between the two taps is within the range of 47.0 ms to 451.3 ms, this can be regarded as indicating the possibility of a rhythmical tap action with the two taps as base points. Hereinafter, the minimum and maximum values of this time range will be respectively designated S min  and S max . Further, the upper limit to which two taps can be regarded as being performed simultaneously will be designated D max . 
     It has been further found that a relatively long pause tends to be taken. 
     For a series of taps to be determined as a rhythmical tap, the following criteria need to be met. 
     Criterion 1: Device Validity 
     For a tap sequence T 1 , T 2 , T 3  (see  FIG. 1 ) to be determined as rhythm ABA, the following conditions need to be met.
 
device ( T   1 )≠device ( T   2 )
 
device ( T   1 )=device ( T   3 )
 
     In this case, device (T) indicates a device on which tap T is performed. 
     Criterion 2: Validity of the Interval Sequence 
     For a tap sequence T 1 , T 2 , T 3  to be determined as rhythm ABA, letting the time between tap A and the next tap B be L 1 , and the time between tap B and the next tap A be L 2  (see FIG.  1 ), the following conditions need to be met.
 
 S   min   ≤L   1   ≤S   max  
 
     L 2  falls within the 95% prediction interval based on L 1  of rhythm ABA. 
       FIG. 3  illustrates the results of regression analysis of L 1  and L 2  for rhythm ABA. The horizontal axis of the graph represents L 1  (the time between tap A and the next tap B), and the vertical axis represents L 2  (the time between tap B and the next tap A). Letting L 1 =x, and L 2 =y, then the following equations hold.
 
 y= 0.9152 x+ 37.269
 
 R   2 =0.8916
 
     Likewise, performing regression analysis on other rhythms yields the following equations. 
     Rhythm AAB:
 
 L   2 =1.03 L   1 −7.1
 
Rhythm ABB:
 
 L   2 =0.85 L   1 +43.7
 
rhythm ABAB:
 
 L   2 =0.96 L   1 +14.1,  L   3 =0.95 L   1 +10.6
 
Rhythm AB-A:
 
 L   2 =1.54 L   1 +183.0
 
Rhythm AB-B:
 
 L   2 =1.48 L   1 +195.9
 
Rhythm AB-C:
 
 L   2 =1.45 L   1 +207.9
 
Rhythm ABABA:
 
 L   2 =0.93 L   1 +22.5,  L   3 =0.97 L   1 −0.5,  L   4 =0.92 L   1 +36.4
 
Rhythm ABA-A:
 
 L   2 =0.97 L   1 +28.0,  L   3 =1.54 L   1 +166.5
 
Rhythm ABA-C:
 
 L   2 =0.95 L   1 +34.1,  L   3 =1.44 L   1 +170.0
 
Rhythm AB-AB:
 
 L   2 =1.59 L   1 +146.5,  L   3 =0.95 L   1 +0.3
 
     L 3  for rhythm ABAB means, with the time from the first tap A to the next tap B taken as L 1 , and the time from this tap B to the next tap A taken as L 2 , the time L 3  from this tap A to the last tap B. Likewise, L 4  for rhythm ABABA means the time from the second tap B to the last tap A. Generally, the time between the i-th tap and the (i+1)-th tap can be expressed as Li. 
     The 95% prediction interval for each of L 2 , L 3 , and L 4  based on L 1  is
 
 y′−t ( n−p− 1,0.975)* SE≤y≤y′+t ( n−p− 1,0.975)* SE,  
 
where y′ is a predicted value of y, which is calculated from the results of regression analysis obtained for each of the above-mentioned rhythms. SE denotes the standard deviation obtained by the regression analysis. t(n−p−1, 0.975) denotes the 0.975 percentile (a numerical value indicating the ordinal position counted from bottom in the whole taken as 100) of the t-distribution with (n−p−1) degrees of freedom, n denotes the sample size of the observation data, and p denotes the number of explanatory variables, which is 1 in this case.
 
     Now, rhythm ABA-C will be described as an example.  FIG. 4  schematically illustrates a tap sequence T 1 , T 2 , T 3 , T 4 , T 5 . First, a user performs tap T 1  with the dominant hand, then tap T 2  with the non-dominant hand after T 1 , then tap T 3  with the dominant hand after L 2 , and lastly, taps T 4  and T 5  with both hands after L 3 . The time difference when taps  1   4  and T 5  are performed with both hands is designated L 4 . For the sequence of these taps T 1 , T 2 , T 3 , T 4 , and T 5  to be determined as rhythm ABA-C, the following criteria need to be met. 
     Criterion 1: Device Validity
 
device ( T   1 )≠device ( T   2 )
 
device ( T   1 )=device ( T   3 )
 
device ( T   4 )≠device ( T   5 )
 
and
 
device ( T   1 )=device ( T   4 ), or device ( T   1 )=device ( T   5 )
 
Criterion 2: Validity of a First Interval
 
 S   min   ≤L   1   ≤S   max  
 
Criterion 3: Validity of a Second Interval
 
     Letting the 95% prediction interval for L 2  based on L 1  of rhythm ABA-C be [min 2 , max 2 ], tap T 3  falls within the interval [T 2 +min 2 , T 2 +max 2 ]. 
     Criterion 4: Validity of a Third Interval 
     Letting the 95% prediction interval for L 3  based on L 1  of rhythm ABA-C be [min 3 , max 3 ], tap T 4  falls within the interval [T 3 +min 3 , T 3 +max 3 ]. 
     Criterion 5: Validity of a Fourth Interval 
     This represents the validity of simultaneous taps, which is expressed as follows.
 
0≤ L   4   ≤D   max  
 
     The above criteria are used in determining a given tap sequence to be a specific rhythm. If multiple rhythms include a particular rhythm that can be easily determined, in other words, a particular rhythm that is unlikely to be erroneously detected, then such a rhythm can be selected as a rhythm that serves as a trigger for performing transmission and reception of data between multiple data communication devices. 
       FIG. 5  illustrates the frequency of erroneous detections of each rhythm for a case where the number of users (persons) is varied as 1, 5, 10, and 20, and each device is tapped so as to achieve each rhythm.  FIG. 5  illustrates the total number of erroneous detections for five days. For example, when the number of users is 10, the total numbers of erroneous detections for individual rhythms are as follows. 
     ABAB→1 
     AB-C→0 
     ABABA→0 
     ABA-A→0 
     ABA-C→0 
     AB-AB→1 
     It can be appreciated form the above results that these rhythms can be determined with almost complete reliability and accuracy. Therefore, these rhythms may be used to reliably and accurately establish transmission and reception of data between data communication devices. Generally, use of four or more taps enables a marked decrease in the frequency of erroneous detection. 
     As described above, rhythms with relatively low risks of erroneous detection are selected, and the selected rhythms are used to permit communication of data between multiple devices. 
     Multiple devices may be used by the same user, or each device may be used by a different user. In the former case, the same person has multiple (e.g., two) devices, and the person taps one of the devices with the dominant hand and taps the other device with the non-dominant hand to permit communication of data between two devices. In the latter case, each user taps the user&#39;s own device with the dominant hand or the non-dominant hand to permit communication of data between multiple devices. 
     Next, the exemplary embodiments will be described with greater specificity. 
     First Exemplary Embodiment 
       FIG. 6  illustrates a system configuration according to a first exemplary embodiment. The system is a server-client system. Two client terminals (to be referred to as “clients” hereinafter)  10   a  and  10   b  are connected to a server  12  via a communication line. The client  10   a , which is an information processing device, functions as a first terminal, and the client  10   b , which is an information processing device, functions as a second terminal. The server  12  functions as an information management device. 
     The clients  10   a  and  10   b  each include a device registration unit, an event acquisition unit, a command receiving unit, a message transmitting unit, and a message receiving unit. 
     The device registration unit acquires, based on an instruction from a user, the device name and device ID of a client device, and transmits the acquired device name and device ID to the server  12 . 
     The event acquisition unit functions as an input unit that receives an input. The event acquisition unit acquires an input (event) that has occurred on a client, and transmits the corresponding device ID and event type to the server  12 . An input according to the exemplary embodiment is a tap, and the event acquisition unit may be specifically implemented by a touch panel. 
     The command receiving unit receives a command from a command management unit of the server  12 , and transmits a message corresponding to the command to a destination device (client). 
     The message transmitting unit generates a message and transmits the message to a destination device (client), based on an instruction from the command receiving unit. 
     The message receiving unit receives a message from another device (client), and executes a process corresponding to the received message. 
     The server  12  includes a device management unit, an event management unit, a rhythmical tap detector, and a command management unit. The server  12  also includes the following databases (DBs): a device table DB  121 , an event table DB  122 , a rhythm table DB  123 , and a command table DB  124 . 
     The device management unit registers, into the device table DB  121 , a device name and a device ID transmitted from the device registration unit of each of the clients  10   a  and  10   b.    
     The event management unit registers, into the event table DB  122 , a device ID and event time transmitted from the event acquisition unit of each of the clients  10   a  and  10   b.    
     The rhythmical tap detector detects a rhythmical tap by determining, whenever a new event is added to the event table DB  122 , whether a new rhythmical tap has occurred. The rhythmical tap detector detects a rhythmical tap by referencing a rhythm table stored in the rhythm table DB  123  and determining the validity of intervals in the tap sequence. 
     The command management unit functions as a permitting unit that permits communication of data between clients. In response to detection of a rhythmical tap by the rhythmical tap detector, the command management unit transmits, to each of the clients  10   a  and  10   b , a command instructing that a message be transmitted. The type of the command to be transmitted varies for each rhythm. Thus, the command management unit references a command table stored in the command table DB  124  to transmit a command instruction corresponding to the detected rhythmical tap. 
     Hereinafter, processes executed by various units will be described in detail. 
     The device management unit of the server  12  registers device names and device IDs received from the respective device registration units of the clients  10   a  and  10   b  into the device table DB  121 . In its simplest form, the information registered at this time is a list of device IDs. Specifically, the list contains information such as ID=1→client  10   a , ID=2→client  10   b , and so on. 
     There are several methods for registering devices. For example, devices to be registered may be specified via a dialog or as files. Alternatively, when a meeting is to be conducted by multiple clients, device registration may be performed simultaneously with user registration by a method such as holding an NFC device over the devices to be registered at the beginning of the meeting. At this time, it is desired that the registration of devices be valid only for the duration of the meeting, and be cancelled after the meeting ends. 
     Upon detecting the occurrence of an event on the client  10   a  or  10   b , the event management unit of the server  12  registers the corresponding device ID and event type, and the time of receipt of the event into the event table DB  122 . The following is an example of a device ID and an event type transmitted from the event acquisition unit of the client  10   a  or  10   b.    
     Device:  2   
     Event: press 
       FIG. 7  illustrates an example of an event table registered in the event table DB  122 . Event ID, time of receipt, device ID, and event type are registered in the event table in association with each other. It is assumed that there is no delay in communication between each of the clients  10   a  and  10   b  and the server  12 , and the time of event occurrence on each of the clients  10   a  and  10   b  is ignored. Of course, both the time of event occurrence and the time of event receipt may be registered in the event table DB  122 . 
     The rhythmical tap detector of the server  12  uses event sequences, that is, tap sequences registered in the event table DB  122  to detect a specific rhythm. An algorithm for rhythmical tap detection will be described below by way of several rhythms as examples. 
     Detection of Rhythm ABAB 
       FIG. 8  schematically illustrates a case where taps have been performed on each of the clients  10   a  and  10   b . In  FIG. 8 , “A” represents tapping on the client  10   a , and “B” represents tapping on the client  10   b . This corresponds to a case where, first, tap T 1  is performed on the client  10   a , followed by tap T 2  on the client  10   b , followed by tap T 3  on the client  10   a , and then followed by tap T 4  on the client  10   b . The time between tap T 1  and tap T 2  is designated L 1 , the time between tap T 2  and tap T 3  is designated L 2 , and the time between tap T 3  and tap T 4  is designated L 3 . 
     To determine whether the sequence of these taps, T 1 , T 2 , T 3 , and T 4 , constitutes rhythmical tap ABAB, it is determined whether the following criteria are met. 
     Criterion 1: Device Validity
 
device ( T   1 )≠device ( T   2 )
 
device ( T   1 )=device ( T   3 )
 
device ( T   2 )=device ( T   4 )
 
Criterion 2: Validity of a First Interval
 
 S   min   ≤L   1   ≤S   max  
 
Criterion 3: Validity of a Second Interval
 
     Letting the 95% prediction interval for L 2  based on L 1  of rhythm ABAB be [min 2 , max 2 ], T 3  falls within the interval [T 2 +min 2 , T 2 +max 2 ]. 
     Criterion 4: Validity of a Third Interval 
     Letting the 95% prediction interval for L 3  based on L 1  of rhythm ABAB be [min 3 , max 3 ], T 4  falls within the interval [T 3 +min 3 , T 3 +max 3 ]. 
     In this case, S min , S max , min 2 , max 2 , min 3 , and max 3  are registered in the rhythm table DB  123  in advance. Alternatively, these values may be calculated from L 1  by using the results of regression analysis. 
       FIG. 9  illustrates an example of a rhythm table stored in the rhythm table DB  123 . For each rhythm, the gradient, intercept, and the values of “t” and “SE” of the results of regression analysis (linear regression) are registered in the rhythm table in association with each other. These parameters are necessary for calculating, for each rhythm, the lower and upper limits of the 95% prediction interval for each of L 2 , L 3 , and L 4  based on L 1 . For example, the lower limit min 2  and upper limit max 2  of the 95% prediction interval for L 2  for rhythm ABA are calculated follows.
 
min 2 =0.91 *L   1 +37.2−1.96*1676
 
max 2 =0.91* L   1 *37.2+1.96*1676
 
     For rhythm ABA-C, the fourth tap is a simultaneous tap on each of the clients  10   a  and  10   b . In this case, all values are registered as zero for the sake of convenience. 
     The detection algorithm used is as follows. 
     A set of valid tap subsequences of ABAB is designated R ABAB . A valid tap subsequence refers to a tap subsequence that satisfies both the device validity and interval validity conditions. 
     When tap T occurs, for all of the elements r of R ABAB , 
     when r=1 (r=T 1 ), and 
     when S min ≤T−T 1  (=L 1 )≤S max , if device (T 1 )≠device (T), then r is replaced by T 1 T. When S max &lt;T−T 1  (=L 1 ), r is removed from R ABAB . 
     When r=2 (r=T 1 T 2 ), and 
     when min 2 ≤T−T 2  (=L 2 )&lt;max 2 , if device (T 1 )=device (T), then r is replaced by T 1 T 2 T. When max 2 &lt;T−T 2 , r is removed from R ABAB . 
     When r=3 (r=T 1 T 2 T 3 ), and 
     when min 3 ≤T−T 3  (=L 3 )≤max 3 , if device (T 2 )=device (T), T 1 T 2 T 3 T is determined to be a rhythmical tap. When max 3 &lt;T−T 3 , r is removed from R ABAB . 
     The above process is repeatedly executed for all of the elements r to determine whether the tap sequence T 1 , T 2 , T 3 , T 4  constitutes rhythm ABAB. 
     Detection of Rhythm AB-C 
       FIG. 10  schematically illustrates a case where taps have been performed on each of the clients  10   a  and  10   b . In  FIG. 10 , “A” represents tapping on the client  10   a , and “B” represents tapping on the client  10   b . This corresponds to a case where tap T 1  is performed on the client  10   a , followed by tap T 2  on the client  10   b , which is then followed by taps T 3  and T 4  performed substantially simultaneously on the client  10   b  and the client  10   a , respectively. The time between tap T 1  and tap T 2  is designated L 1 , the time between tap T 2  and tap T 3  is designated L 2 , and the time between tap T 3  and tap T 4  is designated L 3 . 
     To determine whether the sequence of these taps T 1 , T 2 , T 3 , and T 4  constitutes rhythmical tap AB-C, it is determined whether the following criteria are met. 
     Criterion 1: Device Validity
 
device ( T   1 )≠device ( T   2 )
 
device ( T   3 )≠device ( T   4 )
 
and,
 
device ( T   1 )=device ( T   3 ), or device ( T   1 )=device ( T   4 )
 
Criterion 2: Validity of a First Interval
 
 S   min   ≤L   1   ≤S   max  
 
Criterion 3: Validity of a Second Interval
 
     Letting the 95% prediction interval for L 2  based on L 1  of rhythm AB-C be [min 2 , max 2 ], T 3  falls within the interval [T 2 +min 2 , T 2 +max 2 ]. 
     Criterion 4: Validity of a Third Interval
 
0≤ L   3   ≤D   max  
 
     S min , S max , min 2 , max 2 , and D max  are registered in the rhythm table DB  123  in advance. Alternatively, these values may be calculated from L 1  by using the results of regression analysis. 
     The detection algorithm used is as follows. 
     When r=1 (r=T 1 ), and 
     when S min ≤T−T 1  (=L 1 )≤S max , if device (T 1 )≠device (T), then r is replaced by T 1 T. When S max &lt;T−T 1  (=L 1 ), r is removed from R ABAB . 
     When r=2 (r=T 1 T 2 ), and 
     when min 2 ≤T−T 2  (=L 2 ) max 2 , if device (T 1 )=device (T), or device (T 2 )=device (T), then r is replaced by T 1 T 2 T. When max 2 &lt;T−T 2 , r is removed from R ABAB . 
     When r=3 (r=T 1 T 2 T 3 ), and 
     when 0≤T−T 3 ≤D max , if device (T 1 )=device (T), or device (T 2 )=device (T), then T 1 T 2 T 3 T is determined to be a rhythmical tap. When D max &lt;T−T 3 , r is removed from R ABAB . 
     The above process is repeatedly executed for all of the elements r to determine whether the tap sequence T 1 , T 2 , T 3 , T 4  constitutes rhythm AB-C. 
     Situations can arise in which multiple rhythmical taps are detected simultaneously. An example of such a situation is when rhythm ABA and rhythm ABABA are detected. Which rhythm is to be given priority in such a case may be determined in advance. For example, priority is given to the longer of the two rhythms. This is because the probability of occurrence of the longer rhythm is lower, and thus use of such a rhythm ensures a corresponding improvement in reliability. 
       FIG. 11  is a schematic representation of a process performed upon detection of a specific rhythm. In response to detection of a rhythmical tap by the rhythmical tap detector of the server  12 , the command management unit reads a command corresponding to the detected rhythmical tap from the command table DB  124 . The command management unit transmits the read command (the command corresponding to the detected rhythm) to the command receiving unit of the client  10   a . The message transmitting unit of the client  10   a  transmits a message to the client  10   b . The message receiving unit of the client  10   b  executes a process according to the received message. 
       FIG. 12  illustrates an example of a command table registered in the command table DB  124 . Rhythms and commands are stored in the command table in association with each other. The following is an example of rhythms and commands stored in the command table. 
     Rhythm ABA: TextSend 
     Rhythm AAB: FileSend 
     A command in this case is a command to be executed between the clients  10   a  and  10   b  for which a rhythm has been detected. Such a command is transmitted to the client that has executed the first tap T 1  of the detected rhythm. 
     For example, if rhythm AAB is detected, the corresponding command is FileSend (transmission of an active file). In this case, since the first tap T 1  has been executed by the client  10   a , the command management unit transmits, to the client  10   a , a command instructing the client  10   a  to “transmit a file to the client  10   b ”. A FileSend command is a command that means transmission of an active file. The destination of the active file in this case is specified to be the client  10   b , which is the device on which tap T 3  corresponding to tap B has been performed. 
     At the client  10   a , the command receiving unit receives the command from the server  12 , and the message transmitting unit transmits a message and a file to the client  10   b . At the client  10   b , the message receiving unit receives the message, and executes a process according to the type of the received message. For example, the received file is displayed on the display of the client  10   b.    
     If a rhythmical tap is to be detected for multiple types of rhythms, basically, different algorithms are executed in a simultaneous parallel fashion for each type of rhythm. This is because the determination criteria or parameters used differ for each rhythm. For example, a case is considered in which three types of rhythms, ABA, ABB, and ABAB, are to be detected. In this case, when the server  12  receives the event of tap T from the client  10   a  or  10   b , all of the detection algorithms for the three types of rhythms ABA, ABB, and ABAB are executed in a parallel fashion. At this time, it is possible that rhythmical taps corresponding to different rhythms are detected at the same time. Thus, as mentioned above, it is desirable to determine which detection algorithm is to be given priority in advance. Detection algorithms may be executed in the order of their priority rank, and at the time when a rhythmical tap is detected, rhythmical tap detection for tap T may be ended. 
     There is also a possibility that different rhythms beginning with the same tap may be detected. This corresponds to detection of, for example, ABA and ABAB. ABAB corresponds to an extension of ABA. For cases where priority is given to detection of longer tap sequences, detection of ABA is not to be immediately taken to mean that ABA has been detected. For such cases, after ABA is detected, it needs to be waited for a while until it is confirmed that ABAB is not detected, only after which it is determined that ABA has been detected. In other words, the tapped sequence is determined to be ABA by the fact that ABAB has not been detected. In an alternative configuration, at the point when ABA is detected, ABA is provisionally determined to be the tapped sequence, and if ABAB is not detected thereafter, then ABA is finally determined to be the tapped sequence. 
     Second Exemplary Embodiment 
       FIG. 13  illustrates a system configuration according to a second exemplary embodiment. The system is of a peer-to-peer (P2P) configuration in which two clients  10   a  and  10   b  communicate with each other. The clients  10   a  and  10   b  both function as information processing devices. 
     The clients  10   a  and  10   b  each include an event acquisition unit, a rhythmical tap determining unit, a message transmitting unit, and a message receiving unit, and also includes, as databases (DBs), a rhythm table DB and a command table DB. In  FIG. 13 , the rhythm table DB and the command table DB of the client  10   a  are respectively designated as a rhythm table DB  10   a   1  and a command table DB  10   a   2 , and the rhythm table DB and the command table DB of the client  10   b  are respectively designated as a rhythm table DB  10   b   1  and a command table DB  10   b   2 . 
     The event acquisition unit of each of the clients  10   a  and  10   b  acquires an event that has occurred on the client  10   a  or  10   b , and broadcasts an event message to the other client. 
     The rhythmical tap determining unit of each of the clients  10   a  and  10   b  determines, for each of multiple valid event messages, whether to continue/accept/reject a rhythmical tap determination. The rhythm tables DB  10   a   1  and  10   b   1  are referenced for the determination. 
     If the determination result is “continue”, the rhythmical tap determining unit transmits the event message to the corresponding client. 
     If the determination result is “accept”, the rhythmical tap determining unit references the command table DB  10   a   2  or  10   b   2 , and requests the message transmitting unit to transmit the corresponding command to the corresponding client. 
     If the determination result is “reject”, the rhythmical tap determining unit terminates exchanging of event messages with the other client. 
     The message transmitting unit of each of the clients  10   a  and  10   b  generates a message based on a command, and transmits the message to the destination client. 
     The message receiving unit of each of the clients  10   a  and  10   b  receives a message from the other client, and executes a process according to the received message. 
     Although the function of the event acquisition unit is basically the same as that in the first exemplary embodiment, it is to be noted that unlike in the first exemplary embodiment, the event acquisition unit broadcasts an event message to all other clients, rather than transmitting the event message to the server  12 . Accordingly, if, for example, there are clients  10   c ,  10   d , and so on in addition to the clients  10   a  and  10   b , the event acquisition unit of the client  10   a  transmits an acquired event to all of the other clients  10   b ,  10   c ,  10   d , and so on. 
       FIG. 14  illustrates the data structure of an event message broadcast between clients. 
     SubSequence represents a rhythmical tap subsequence, and means that the subsequence up to that position satisfies device validity and interval validity. That is, Subsequence refers to such a tap sequence that can possibly form a rhythmical tap with addition of a sequence of several more taps. Candidates represent a set of rhythm candidates that a tap subsequence satisfies. Although a large number of rhythm candidates can initially exist, the set of tap subsequences is narrowed down as the tap subsequence becomes longer. 
     Although FirstInterval may be calculated as T 2 −T 1 , there is a possibility of clocks not being synchronized between different clients. Accordingly, the time difference between taps on the same client, or the difference between the time of tapping and the time of arrival at device (T 2 ) is used as the length of a first interval. 
     The ArrivalTime field, which is blank at the time of transmission of an event message, records the time of arrival of the message at the receiving end of the message. 
       FIG. 15  is a sequence diagram illustrating exchange of event messages between clients, with rhythm ABAB taken as an example. 
     A tap sequence on the client  10   a  is designated T 1a , T 3a , and a tap sequence on the client  10   b  is designated T 2b , T 4b . When tap T 1a  is detected at time T 1a , the event acquisition unit of the client  10   a  detects this event, and broadcasts the following event message to the other client. 
     SubSequence: T 1a    
     Candidates: ABAB 
     First Interval: 
     ArrivalTime: 
     Since the second exemplary embodiment assumes the existence of the clients  10   a  and  10   b , the event acquisition unit of the client  10   a  transmits the event message to the client  10   b . It is assumed that the event message arrives at the client  10   b  at time T 1b . 
     Next, when tap T 2b  is detected at time T 2b , the event acquisition unit of the client  10   b  detects this event, and broadcasts the following event message to the other client. 
     SubSequence: T 1a T 2b    
     Candidates: ABAB 
     FirstInterval: T 2b −T 1b (=L 1 ) 
     ArrivalTime: 
     In the second exemplary embodiment, the event message is transmitted to the client  10   a . At this time, the rhythmical tap determining unit of the client  10   b  calculates T 2b −T 1b , and if this falls within the interval [S min , S max ], the rhythmical tap determining unit determines to “continue” and transmits the event message to the client  10   a . If multiple potential rhythm candidates exist, all of such rhythm candidates are transmitted. It is assumed that the event message arrives at the client  10   a  at time T 2a . 
     Next, when tap T 3a  is detected at time T 3a , the event acquisition unit of the client  10   a  detects this event, and broadcasts the following event message to the client  10   b.    
     SubSequence: T 1a T 2b T 3a    
     Candidates: ABAB 
     FirstInterval: L 1    
     ArrivalTime: 
     At this time, the rhythmical tap determining unit of the client  10   a  calculates T 3a −T 2b , and if this falls within the interval [min 2 , max 2 ], and device (T 1a )=device (T 3a ), the rhythmical tap determining unit determines to “continue”, and transmits the event message to the client  10   b . It is assumed that the event message arrives at the client  10   b  at time T 3b . 
     Next, when tap T 4b  is detected at time T 4b , the event acquisition unit of the client  10   b  detects this event. Further, the rhythmical tap determining unit of the client  10   b  calculates T 4b −T 3b , and if this falls within the interval [min 3 , max 3 ], and device (T 1a )=device (T 4a ), the rhythmical tap determining unit detects rhythmical tap ABAB, and determines to “accept”. The rhythmical tap determining unit of the client  10   b  references the command table DB  10   b   2 , and requests the message transmitting unit to transmit the corresponding command to the client  10   a . The message receiving unit of the client  10   a  receives the command from the client  10   b , and executes the corresponding process. Examples of such a corresponding process include transmission of a file to the client  10   b.    
     A detailed description of the algorithm used by the rhythmical tap determining unit will be given below. 
     Immediately following receipt of event message E by a client, the time of arrival of the event message is recorded into the ArrivalTime field for event message E. 
     If an event, for example, a Press event has occurred on the client, the following process is executed for each of event messages retained by the client. 
     When SubSequence of the event message has a length of 1 (T 1 ), letting the time of arrival of T 1  be T 1 *, if S min ≤T−T 1 *≤S max , then SubSequence of event message E is substituted by T 1 T. FirstInterval is set to T−T 1 *. Further, the event message is transmitted to the client of device (T 1 ). When S max &lt;T−T 1 *, the event message is removed from the set of event messages. 
     When SubSequence of the event message has a length of 2 (T 1 T 2 ), the time of arrival of T 2  is designated T 2 *. Letting FirstInterval of the event message be L 1 , when min 2 ≤T−T 2 *≤max 2 , and device (T 1 )=device (T), SubSequence of the event message is substituted by T 1 T 2 T. Further, the event message is transmitted to the client of device (T 2 ). When S max &lt;T−T 2 *, the event message is removed from the set of event messages. 
     When SubSequence of the event message has a length of 3 (T 1 T 2 T 3 ), the time of arrival of T 3  is designated T 3 *. Letting FirstInterval of the event message be L 1 , when min 3 ≤T−T 3 *≤max 3 , and device (T 2 )=device (T), a rhythmical tap T 1 T 2 T 3  is detected. When S max &lt;T−T 2 *, the event message is removed from the set of event messages. 
     As described above, according to the second exemplary embodiment, it is not necessary to synchronize time between multiple clients. It is not necessary for each client to transmit time data, either. It is to be noted, however, that transmitting time data provides an advantage of enabling precise interval estimation because a communication delay can be calculated upon return of an event. 
     The second exemplary embodiment does not involve centralized management via the server  12 . Accordingly, information such as knowledge about rhythms and the interval estimation method for each individual rhythm needs to be retained by each client. Further, when a change is to be made to the algorithm, this is not achieved simply by upgrading the version of the server  12  but requires the software of all clients to be changed. 
     Third Exemplary Embodiment 
     The peer-to-peer configuration according to the second exemplary embodiment is designed such that, for each event, an event message is broadcast to all the other clients. This can lead to increases in network traffic. 
     To avoid such increases in network traffic, the third exemplary embodiment employs the following configuration. That is, only after a certain amount of event sequence accumulates, the event sequence is broadcast to other clients. Then, each receiving client that has received the transmitted event sequence checks an event sequence retained by the receiving client against the transmitted event sequence to determine whether the combination of the transmitted event sequence and the event sequence retained by the receiving client constitutes a rhythmical tap as a whole. Rather than broadcasting a message for each single event, an event sequence made up of multiple events is transmitted, thus reducing network traffic. Further, rather than transmitting a message upon every occurrence of an event, a message is transmitted only when a sequence of events satisfies a certain condition, thus reducing network traffic. 
       FIG. 16  schematically illustrates an example of tap sequences on the clients  10   a  and  10   b . This corresponds to rhythmical tap ABA-C, and it is assumed that a tap sequence T 1 , T 3 , T 4  has occurred on the client  10   a , and a tap sequence T 2 , T 5  has occurred on the client  10   b.    
     Hereinafter, of the sequence of taps constituting a rhythmical tap, the subsequence that occurs on the client  10   a  (the client that is tapped earlier) will be referred to as “leading-half subsequence” (T 1 T 3 T 4 ), and the subsequence that occurs on the client  10   b  (the client that is tapped later) will be referred to as “trailing-half subsequence” (T 2 T 5 ). 
     If an event sequence that has occurred on a given client is identified to be the leading-half subsequence (if the interval width of the tap sequence is likely to be that of the leading-half subsequence of a specific rhythm), the client broadcasts the leading-half subsequence to the other clients. The client that has received the leading-half subsequence determines whether the transmitted tap sequence constitutes a rhythmical tap when combined with a tap sequence retained by the receiving client. 
     Although the system configuration according to the third exemplary embodiment is substantially the same as that according to the second exemplary embodiment, in the third exemplary embodiment, each client further includes an event retaining unit and a subsequence determining unit. 
     As in the second exemplary embodiment, the event acquisition unit acquires an event that has occurred on a client, and broadcasts the acquired event to the other clients. 
     The event retaining unit retains the event for a predetermined period of time. 
     The subsequence determining unit searches event sequences in the event table for the leading-half subsequence of a specific rhythm. If such a leading-half subsequence is found, the subsequence determining unit broadcasts the leading-half subsequence to the other clients. 
     When the rhythmical tap determining unit of a client receives a leading-half subsequence from another client, the rhythmical tap determining unit checks the leading-half subsequence against each event sequence in the event table retained by the receiving client to determine whether the combination of the leading-half subsequence and the event sequence constitutes a rhythmical tap. If a rhythmical tap is detected, the rhythmical tap determining unit references the command table DB  10   a   2  or  10   b   2 , and requests the message transmitting unit to transmit the corresponding command to the corresponding client. 
       FIG. 17  illustrates an example of an event table retained by the event retaining unit. In the event table, event ID and time are stored in association with each other. Each event acquired by the event acquisition unit is sequentially stored into the event table. Any event for which a predetermined time T max  has elapsed since its storage is removed from the table, because even if retained any longer, such an event does not become to form a leading-half subsequence, nor does such an event form a rhythmical tap even when combined with a transmitted leading-half subsequence. T max  is calculated as follows. 
     That is, first, the maximum value of S max  is selected for the first interval. Next, with this taken as L 1 , the maximum estimated value of L 2  is selected. In this way, the maximum values of L 3  and L 4  are also selected one after the other, and the sum of all of these values for the maximum number of taps is determined to be T max . 
       FIGS. 18 and 19  each schematically illustrate a process executed by the subsequence determining unit. Now, suppose that rhythmical tap ABAB as illustrated in  FIG. 18  exists. 
     It is necessary to determine whether taps T 1  and T 3  constitute a leading-half subsequence, only from taps T 1  and T 3  without the existence of taps T 2  and T 4 . Since the length of L 1  is unknown, the timing of tap T 3  needs to be predicted while assuming both minimum and maximum values of L 1 . 
     First, the minimum value S min  of the 95% confidence interval for L 2  when L 1  is minimum is acquired. Next, the maximum value S max  of the 95% confidence interval for L 2  when L 1  is maximum is acquired. Then, if tap T 3  falls within the interval [T 1 +S min , T 1 +S max ], it is determined that taps T 1  and T 3  have a possibility of constituting the leading-half subsequence of rhythm ABAB. 
       FIG. 19  illustrates an example of data transmitted by the subsequence determining unit. The subsequence determining unit transmits information such as type of rhythm (Rhythm), tap sequence (SubSequence), time of transmission (Time), and device (Device). 
     Rhythm ABAB is determined as described below. 
     First, for a given receiving client, the difference Diff between the time at the receiving client and the transmitting client is calculated, and this is used as the time difference between the system clocks of the receiving and transmitting clients. 
     Next, the event table of the receiving client is searched for event T 2  for which T 2 −T 1 +Diff falls within the interval [S min , S max ]. 
     Next, T 2 −T 1 +Diff is set as L 1 . 
     Next, with the 95% prediction interval for L 2  based on L 1  of rhythm ABAB set as [min 2 , max 2 ], it is determined whether T 3 +Diff falls within the interval [T 2 +min 2 , T 2 +max 2 ]. 
     Next, with the 95% prediction interval for L 3  based on L 1  of rhythm ABAB set as [min 3 , max 3 ], it is determined whether T 4 +Diff falls within the interval [T 3 +min 3 , T 3 +max 3 ]. 
     Since the subsequence determining unit detects a leading-half subsequence for each rhythm, there is a possibility that the leading-half subsequences of multiple rhythms may be detected from the same single tap sequence. In this case, as many leading-half subsequences as the number of detected rhythms may be broadcast to the other clients. 
     Lastly, the criteria for a tap sequence T 1 , T 2 , T 3 , T 4  to be determined as rhythmical tap ABAB are as follows. 
     Criterion 1: Device Validity
 
device ( T   1 )≠device ( T   2 ), device ( T   1 )=device ( T   3 ), device ( T   2 )=device ( T   4 )
 
     Criterion 2: Validity of a First Interval
 
 S   min   ≤L   1   ≤S   max  
 
     Criterion 3: Validity of a Second Interval 
     Letting the 95% prediction interval for L 2  based on L 1  of rhythm ABAB be [min 2 , max 2 ], T 3  falls within the interval [T 2 +min 2 , T 2 +max 2 ]. 
     Criterion 4: Validity of a Third Interval 
     Letting the 95% prediction interval for L 3  based on L 1  of rhythm ABAB be [min 3 , max 3 ], T 4  falls within the interval [T 3 +min 3 , T 3 +max 3 ]. 
     Values such as min 2 , max 2 , min 3 , or max 3  are calculated by referencing the rhythm table DB  10   a   1  or  10   b   1  to acquire necessary parameters, and using the value of L 1 . 
     Clients according to the exemplary embodiments of the present invention described above may be any information terminals such as smartphones, tablet terminals, and personal computers. Further, the functional blocks of each client according to the exemplary embodiments are implemented by the CPU reading a process program stored in a program memory such as a ROM, an SSD, or an HD, and sequentially executing the program with a RAM used as a working memory. The same applies to the functional blocks of the server  12 . 
     The following provides a list of major functions that the CPU of a server in a server-client system executes by means of a process program. 
     (1) The order and time intervals of three or more inputs made on multiple clients (terminals) are acquired. 
     (2) It is determined whether the acquired order and time intervals match a predetermined pattern. 
     (3) If a match occurs, a command corresponding to the predetermined pattern is transmitted between multiple clients so as to be executed. 
     Further, the following provides a list of major functions that the CPU of a client in a peer-to-peer system executes by means of a process program. 
     (1) When an input is made, the input is broadcast to the other clients. 
     (2) The order and time intervals of three or more inputs made on multiple clients (terminals) are acquired. 
     (3) It is determined whether the acquired order and time intervals match a predetermined pattern. 
     (4) If a match occurs, a command corresponding to the predetermined pattern is transmitted between multiple clients so as to be executed. 
     Some of the functions of a client may be implemented not by means of a software process based on execution of a program but by means of a hardware process. Such a hardware process may be performed by using, for example, a circuit such as an ASIC or a field-programmable array (FPGA). 
     The exemplary embodiments of the present invention mentioned above are not limitative but capable of various modifications. Such modifications will be described below. 
     Modification 1 
     The preceding description of the exemplary embodiments is directed to a case where pre-registration, or ad-hoc registration for a meeting or other occasions is performed to establish a group for transmitting and receiving data. The exemplary embodiments may be modified to allow various settings to be selected at this time as appropriate, such as use of a card reader, use of simultaneous tapping of a special rhythm, or use of both a card reader and simultaneous tapping of a special rhythm. Further, the network configuration to be employed may be any one of the followings: wired LAN (delay: 1 ms), wireless LAN (delay: 10 ms), and Bluetooth (registered trademark) (delay: 10 ms). As for the system clock, if the system time at each client and a network delay are managed by the server  12 , it is not necessarily required to synchronize system clocks between clients. 
     Modification 2 
     The preceding description of the exemplary embodiments is directed to an example of a tap made up of a Press event and a Release event. Instead, a tap using the palm of the hand may be used as an input. The present inventors have confirmed that a tap using the palm of the hand further reduces erroneous detection. 
     Modification 3 
     In the exemplary embodiments, the validity of intervals such as the first interval and the second interval is determined to detect a rhythm. In this regard, the tolerance for interval fluctuations in determining interval validity may be made variable. Specifically, for example, the tolerance for fluctuations is set higher when the rhythm is fast (Fast) and when the rhythm is slow (Slow) than is otherwise the case. Specifically, with a typical standard speed as a reference speed, for rhythms faster than this speed and rhythms slower than this speed, the tolerance for fluctuations at the reference speed is increased. The determination of interval validity may be made by taking into account the possibility of reversions occurring in the tap sequence when the rhythm is fast. This is because when a user taps “AAB” very fast, the user may not notice even if “ABA” has been actually tapped. 
     The tolerance for interval fluctuations may be varied according to the user&#39;s age. For example, the tolerance for fluctuations is increased for users with relatively advanced age. As for the method of estimating user&#39;s age, if data such as user&#39;s age or date of birth is stored in the client, user&#39;s age may be estimated by using such data. 
     In one possible configuration, it may be previously specified on the system to increase the tolerance for fluctuations if multiple persons are to beat out a rhythm in a coordinated fashion. This includes, for example, setting the tolerance for fluctuations on the server  12  when ad-hoc registration is to be made for a meeting or other occasions in a server-client system. At this time, as the number of users increases, the tolerance for fluctuations may be increased accordingly. 
     Further, if a user fails to correctly beat out a rhythm and thus data transmission/reception fails, it is presumed that such a user will normally repeat the same operation, and hence the tolerance for fluctuations may be temporarily increased immediately following such a failure. Specifically, the tolerance for fluctuations is increased in accordance with the number of retries. 
     Modification 4 
     To further reduce erroneous operation, the exemplary embodiments may be modified not to permit one-to-one pairing of clients that are separated by a predetermined distance or more in a server-client system or a peer-to-peer system. For example, the distance between clients may be determined by, if each client includes a position detection module such as a GPS, using positional information detected by the module. 
     Modification 5 
     The exemplary embodiments may be modified to use the pressure, contact duration, or contact area of a Press operation in detecting a rhythm. If pressure is to be used, for example, tap A1 performed with a relatively strong pressure and tap A2 performed with a relatively weak pressure are set for tap A and, likewise, tap B1 performed with a relatively strong pressure and tap B2 performed with a relatively weak pressure are set for tap B, and data communication is permitted by use of rhythms of strong and weak beats such as follows:
     A1B1A2   A1B2A1   A2B2A1   

     Whether the pressure applied is strong or weak may be detected by a pressure sensor. 
     If contact duration is to be used, for example, tap A1 as a relatively long tap (long press) and tap A2 as a relatively short tap are set for tap A and, likewise, tap B1 as a relatively long tap and tap B2 as a relatively short tap are set for tap B, and data communication is permitted by use of rhythms of long and short beats such as follows:
     A1B1A2   A1B2A1   A2B2A1   

     Modification 6 
     The exemplary embodiments may be modified to learn individuals&#39; habits, and customize criteria for each individual. This improves usability for each individual whose habits have been learned, and helps to prevent erroneous operation caused by intervention of other users. 
     Modification 7 
     With regard to the exemplary embodiments, due to cultural background, what rhythm is easier to tap than others is presumed to vary depending on the country or region. This fact may be utilized to select a rhythm that ensures a high level of security for each specific country, region, or cultural sphere. 
     For example, in Japan, some tap sequences, such as 3-3-7 beats (tan tan tan-tan tan tan-tan tan tan tan tan tan tan) or the rhythm of a particular famous video game (ja jan jan ja jan jan-ton), are familiar to many Japanese people despite the relatively large number of taps. For such tap sequences, the probability of such a long rhythm happening to occur at the same instant of time is presumably infinitesimally small, even when all devices in the world are considered. Accordingly, a temporary group is established by having multiple persons beat out such a rhythm. Such an action has a secondary advantage of possibly enhancing the sense of togetherness among the participants of a meeting as all the participants beat out such a rhythm together at the beginning of the meeting. 
     Modification 8 
     Generally, for longer rhythms, such as four-part rhythms as opposed to three-part rhythms and five-part rhythms as opposed to four-part rhythms, the probability of accidental occurrence of such rhythms is lower, which translates into relatively higher levels of security. This may be utilized so that commands for processing information of high relative importance are assigned to relatively long rhythms, and commands for processing information of low relative importance are assigned to relatively short rhythms. Specifically, in the command table stored in the command table DB  124  illustrated in  FIG. 12 , commands that vary in importance may be assigned in accordance with the relative length of each rhythm. 
     Modification 9 
     Although the preceding description of the exemplary embodiments is directed to a case where the operation (input) performed is a tap, instead of a tap, shaking of a terminal, that is, a change in acceleration may be used. In this case, the input is an acceleration, and an acceleration sensor or other devices may be used as an input unit. Alternatively, the input may be a predetermined voice input. 
     The preceding description of the exemplary embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical applications, thereby enabling others skilled in the art to understand the invention for various embodiments and with the various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.