JP6790613B2 - 情報処理装置、情報管理装置、及びプログラム - Google Patents

情報処理装置、情報管理装置、及びプログラム Download PDF

Info

Publication number
JP6790613B2
JP6790613B2 JP2016173140A JP2016173140A JP6790613B2 JP 6790613 B2 JP6790613 B2 JP 6790613B2 JP 2016173140 A JP2016173140 A JP 2016173140A JP 2016173140 A JP2016173140 A JP 2016173140A JP 6790613 B2 JP6790613 B2 JP 6790613B2
Authority
JP
Japan
Prior art keywords
subsequent operation
time interval
rhythm
tap
operations
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016173140A
Other languages
English (en)
Other versions
JP2018041172A (ja
Inventor
柴田 博仁
博仁 柴田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujifilm Business Innovation Corp
Original Assignee
Fuji Xerox Co Ltd
Fujifilm Business Innovation Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fuji Xerox Co Ltd, Fujifilm Business Innovation Corp filed Critical Fuji Xerox Co Ltd
Priority to JP2016173140A priority Critical patent/JP6790613B2/ja
Priority to US15/596,335 priority patent/US10326716B2/en
Publication of JP2018041172A publication Critical patent/JP2018041172A/ja
Application granted granted Critical
Publication of JP6790613B2 publication Critical patent/JP6790613B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1684Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675
    • G06F1/169Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675 the I/O peripheral being an integrated pointing device, e.g. trackball in the palm rest area, mini-joystick integrated between keyboard keys, touch pads or touch stripes
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10HELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H1/00Details of electrophonic musical instruments
    • G10H1/36Accompaniment arrangements
    • G10H1/40Rhythm
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16Constructional details or arrangements
    • G06F1/1613Constructional details or arrangements for portable computers
    • G06F1/1633Constructional details or arrangements of portable computers not specific to the type of enclosures covered by groups G06F1/1615 - G06F1/1626
    • G06F1/1684Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675
    • G06F1/1698Constructional details or arrangements related to integrated I/O peripherals not covered by groups G06F1/1635 - G06F1/1675 the I/O peripheral being a sending/receiving arrangement to establish a cordless communication link, e.g. radio or infrared link, integrated cellular phone
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62Establishing a time schedule for servicing the requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2200/00Indexing scheme relating to G06F1/04 - G06F1/32
    • G06F2200/16Indexing scheme relating to G06F1/16 - G06F1/18
    • G06F2200/163Indexing scheme relating to constructional details of the computer
    • G06F2200/1636Sensing arrangement for detection of a tap gesture on the housing
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10HELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2210/00Aspects or methods of musical processing having intrinsic musical character, i.e. involving musical theory or musical parameters or relying on musical knowledge, as applied in electrophonic musical tools or instruments
    • G10H2210/031Musical analysis, i.e. isolation, extraction or identification of musical elements or musical parameters from a raw acoustic signal or from an encoded audio signal
    • G10H2210/076Musical analysis, i.e. isolation, extraction or identification of musical elements or musical parameters from a raw acoustic signal or from an encoded audio signal for extraction of timing, tempo; Beat detection
    • GPHYSICS
    • G10MUSICAL INSTRUMENTS; ACOUSTICS
    • G10HELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/171Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments
    • G10H2240/201Physical layer or hardware aspects of transmission to or from an electrophonic musical instrument, e.g. voltage levels, bit streams, code words or symbols over a physical link connecting network nodes or instruments

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Acoustics & Sound (AREA)
  • User Interface Of Digital Computer (AREA)
  • Information Transfer Between Computers (AREA)
  • Evolutionary Computation (AREA)
  • Technology Law (AREA)
  • Computing Systems (AREA)

Description

本発明は、情報処理装置、情報管理装置、及びプログラムに関する。
従来から、複数のデータ通信装置間でデータ通信を行う際に、自然に、かつ簡便に行うためのユーザインターフェイス技術が提案されている。
特許文献1には、ネットワーク上に、ディスプレイに対しペン型の入力装置で操作入力をすることができる複数のコンピュータが接続されるシステムが記載されている。各コンピュータは、ペンにより操作入力がされると、ネットワーク上の管理テーブルを確認し管理情報が登録されているか判断し、登録されていない場合は、このペンにより選択したアイコンが示すファイル名、アイコンの形状等を管理情報として登録する。また、登録されている場合はこの管理情報を取得する。ペンがディスプレイに接触したら、この管理情報に示されるコンピュータに対しデータの伝送を要求し、ディスプレイ上にアイコンを表示する。
特許文献2には、ユーザが2台の機器を接続したいとき、各機器上の接続ボタンを同時に押下し且つ同時に押下操作を解除することが記載されている。各機器からは接続ボタンの押下及び押下を解除したタイミングを含んだパケットがマルチキャスト送信され、パケットに含まれるタイミングを機器内に記録されているものと比較して、両機器は互いに正しく識別し合う。
特許文献3には、携帯電話機がパーソナルコンピュータの入力表示部に載置されたとき、携帯電話機に内蔵されているRFタグに記憶されている携帯電話機の電話番号が、パーソナルコンピュータに内蔵されているリーダライタにより読み取られ、その電話番号に基づいて、携帯電話機とパーソナルコンピュータとの間において、電話回線が閉結されることが記載されている。
特許第3900605号 特許第4329388号 特許第5120474号
複数のデータ通信装置間での同時押下及び同時押下解除等の同期ジェスチャ(タップ等)によるデータ送受信を行う場合、たまたま同期したジェスチャにより意図しない通信装置と情報通信を行う可能性がある。
本発明は、複数のデータ通信装置間でのデータ送受信において、同時に操作(入力)がなされることでデータ送受信を可能とする場合に比べて、誤動作を低減する情報処理装置、情報管理装置及びプログラムを提供することにある。
請求項1に記載の発明は、自装置で行われた操作と他装置で行われた操作との順序及び時間間隔が予め定められた順序及び時間間隔に一致する場合に、自装置と他装置とで、当該順序及び時間間隔に関連付けられた通信を行う通信手段を有し、前記通信手段は、3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記自装置または前記他装置の利用者の年齢、リトライ回数、前記自装置または前記他装置の利用者の数のいずれかに応じて可変する、情報処理装置である。
請求項2に記載の発明は、予め定められた順序及び時間間隔は複数存在し、前記通信手段は、3以上の操作の順序と操作間の時間間隔とが一致する予め定められた順序及び時間間隔に応じたデータ通信を行う請求項1に記載の情報処理装置である。
請求項3に記載の発明は、前記通信手段は、3以上の操作の順序と操作間の時間間隔とが一致する予め定められた順序及び時間間隔が複数存在する場合にいずれかのパターンを他のパターンに優先させてデータ通信を行う請求項2に記載の情報処理装置である。
請求項4に記載の発明は、前記通信手段は、操作数の多い予め定められた順序及び時間間隔を優先させてデータ通信を行う請求項3に記載の情報処理装置である。
請求項5に記載の発明は、予め定められた順序及び時間間隔は、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作を含む第1パターンと、自装置の操作と、その後の自装置の操作と、その後の前記他装置の操作を含む第2パターンと、自装置の操作と、その後の前記他装置の操作と、その後の前記他装置の操作を含む第3パターンと、自装置の操作と、その後の前記他装置の操作と、その後の自装置及び前記他装置の操作を含む第4パターンの少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置である。
請求項6に記載の発明は、予め定められた順序及び時間間隔は、自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置の操作を含む第1パターンと、自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の前記他装置の操作を含む第2パターンと、自装置の操作と、その後の自装置の操作と、相対的に長いその後の前記他装置の操作を含む第3パターンと、自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置及び前記他装置の操作を含む第4パターンの少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置である。
請求項7に記載の発明は、予め定められた順序及び時間間隔は、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、その後の前記他装置の操作を含む第1パターンと、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の自装置の操作を含む第2パターンと、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の前記他装置の操作を含む第3パターンと、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の自装置及び前記他装置の操作を含む第4パターンと、自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置の操作と、その後の前記他装置の操作を含む第5パターンの少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置である。
請求項8に記載の発明は、予め定められた順序及び時間間隔は、自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作を含む請求項2〜4のいずれかに記載の情報処理装置である。
請求項9に記載の発明は、予め定められた順序及び時間間隔は、自装置及び前記他装置の、相対的に強い操作及び相対的に弱い操作を含む請求項5〜8のいずれかに記載の情報処理装置である。
請求項10に記載の発明は、予め定められた順序及び時間間隔は、自装置及び前記他装置の、相対的に長い操作及び相対的に短い操作を含む請求項5〜8のいずれかに記載の情報処理装置である。
請求項11に記載の発明は、前記通信手段は、前記許容度を、3以上の操作の速度が基準速度よりも遅い場合に相対的に大きくする請求項1〜10のいずれかに記載の情報処理装置である。
請求項12に記載の発明は、前記通信手段は、前記利用者の年齢が高いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置である。
請求項13に記載の発明は、前記通信手段は、前記リトライ回数が多いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置である。
請求項14に記載の発明は、前記通信手段は、前記利用者の数が多いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置である。
請求項15に記載の発明は、前記通信手段は、操作数の相対的に多いパターンと一致した場合には、操作数の相対的に少ないパターンと一致した場合に比べて、相対的に重要度の高いデータ通信を行う請求項2に記載の情報処理装置である。
請求項16に記載の発明は、第1装置で行われた操作と第2装置で行われた操作との順序及び時間間隔が予め定められた順序及び時間間隔とに一致する場合に、前記第1装置と前記第2装置とで、当該順序及び時間間隔とに関連付けられた通信を行わせる制御手段を有し、前記制御手段は、3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記第1装置または前記第2装置の利用者の年齢、リトライ回数、前記第1装置または前記第2装置の利用者の数のいずれかに応じて可変する、情報管理装置である。
請求項17に記載の発明は、コンピュータに、第1装置での操作を取得するステップと、第2装置での操作を取得するステップと、前記第1装置及び前記第2装置から取得した操作の順序と操作間の時間間隔とが予め定められた順序及び時間間隔とに一致する場合に、前記第1装置と前記第2装置とで、当該予め定められた順序及び時間間隔とに関連付けられたデータ通信を行わせるステップと、3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記第1装置または前記第2装置の利用者の年齢、リトライ回数、前記第1装置または前記第2装置の利用者の数のいずれかに応じて可変するステップと、を実行させるプログラムである。
請求項1,1617に記載の発明によれば、同時に操作がなされることでデータ送受信を可能とする場合に比べて、誤動作が少なくなる。また、操作の速度等に依らずにデータ通信を可能とし得る。
請求項2に記載の発明によれば、さらに、パターンに応じたデータ通信が可能となる。
請求項3に記載の発明によれば、さらに、いずれかのパターンを他のパターンに優先させたデータ通信が可能となる。
請求項4に記載の発明によれば、さらに、操作数の多いパターンを優先させたデータ通信を可能とする。
請求項5,6に記載の発明によれば、さらに3つの操作からなるパターンに応じたデータ通信が可能となる。
請求項7に記載の発明によれば、さらに4つの操作からなるパターンに応じたデータ通信が可能となる。
請求項8に記載の発明によれば、さらに5つの操作からなるパターンに応じたデータ通信が可能となる。
請求項9に記載の発明によれば、さらに、相対的に強い操作及び相対的に弱い操作のパターンに応じたデータ通信が可能となる。
請求項10に記載の発明によれば、さらに、相対的に長い操作及び相対的に短い操作のパターンに応じたデータ通信が可能となる。
請求項11に記載の発明によれば、さらに、操作の速度が基準速度よりも遅い場合でもデータ通信を可能とし得る。
請求項12に記載の発明によれば、さらに、利用者の年齢に依らずにデータ通信を可能とし得る。
請求項13に記載の発明によれば、さらに、リトライ後のデータ通信を容易化し得る。
請求項14に記載の発明によれば、さらに、利用者の数に依らずにデータ通信を可能とし得る。
請求項15に記載の発明によれば、さらに、偶発的に生じる確率が低い操作数の相対的に多いパターンによって相対的に重要度の高いデータ通信が可能となる。
複数の装置での入力を示す模式図である。 リズムの速度を変化させた場合のばらつきの度合いを示すグラフ図である。 リズムABAにおける回帰分析結果のグラフ図である。 リズムABA−Cの模式図である。 リズム毎の誤検出頻度を示す説明図である。 第1実施形態のシステム構成図である。 イベントテーブル説明図である。 リズムABABの模式図である。 リズム毎のL2,L3,L4の回帰分析結果を示す説明図である。 リズムAB−Cの模式図である。 リズム検出後の処理説明図である。 コマンドテーブル説明図である。 第2実施形態のシステム構成図である。 イベントメッセージ説明図である。 第2実施形態のシーケンス図である。 リズムABA−Cの模式図である。 イベントテーブル説明図である。 リズムABABの模式図である。 イベントメッセージ説明図である。
以下、図面に基づき本発明の実施形態について説明する。
<基本原理>
まず、本実施形態の基本原理について説明する。
図1は、本実施形態の基本原理を示すシーケンス図である。複数の情報処理装置(データ通信装置等)として、装置A及び装置Bが存在するものとし、装置Aと装置Bとの間の所定パターンでの操作(入力)があったことを示す。
まず装置Aにおいて操作としての入力T1があり、次にL1時間経過後に装置Bにおいて操作としての入力T2があり、次にL2時間経過後に装置Aにおいて入力T3があった場合である。入力T1、T2、T3は、例えば装置A及び装置Bにおいてタッチパネルをタップする行為やボタンを押下操作する行為である。本実施形態では、このような、
T1→T2→T3
という入力の周期的な反復を用いて装置Aと装置Bとの間のデータ送受信を許可する。本実施形態において、入力の周期的な反復を「リズミカルな入力」と称する。入力をタップとすると、リズミカルなタップにより装置Aと装置Bとの間のデータ送受信を許可するということができる。リズミカルな入力によりデータ送受信を許可する利点は以下の通りである。
すなわち、1人でリズムをきざむのは比較的簡単であるから、データ送受信の指定を簡便化できる。また、他人とリズムをきざむのは難しいことから、誤動作及び盗聴を防止し得る。また、長いリズムをきざむのは難しいことから、リズムの長さにより安全性を調整することができる。また、リーダ(指揮者)がいて、相手と協調する意思があれば相手と一緒にリズムをきざむことができることから、一斉配信、つまり1対Nのデータ送信が可能となる。また、この際、タップ等の身体動作を伴うので、誰がどの装置からどの装置にデータを送信しているのかを容易に把握することができ、強調作業がし易くなる。さらに、3連リズム、4連リズム、ABA、A−BA、A−AB等、リズムは多様であることから、拡張性を持たせることができる。
本願発明者等は、複数のリズムについて実験を行った。実験の概要は以下の通りである。
参加者:15名(男性13名、女性2名)
年齢:22歳〜26歳(平均23.8歳)
利き手:右利き14名、左利き1名
作業:左右の手でのリズミカルなタップ99個について、4尺度で主観評価(1〜5の5段階評価で1は最もし難い場合に該当し、5は最もし易い場合に該当する)
・指定スピードでのタップし易さ(1タップ150ms)
・高速でのタップし易さ
・覚え易さ
・馴染み易さ(親しみ易さ)
上記4尺度の平均点を合計した総合評価で上位にランキングされた8個のリズムを選定するとともに、長さ、利き手タップ数のバランスを考慮して、さらに3個のリズムを選定して評価。合計11個のリズムは次の通り。
(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
ここで、Aは利き手のタップ、Bは非利き手のタップ、Cは両手のタップを示し、「−」はタップ間に一定の休止期間があることを示す。例えば「AB−B」は、まず利き手でタップし、次に非利き手でタップし、その後一定の休止期間後に非利き手でタップするリズムを示す。各リズムで最低5回ずつタップしてログを回収した。さらに、
(1)利き手から開始する場合(レギュラー:Regular)
(2)非利き手から開始する場合(Reverse)
についてログを回収した。さらに、
(1)好きなスピード(Preferred)
(2)ゆっくり(Slow)
(3)できるだけ速く(Fast)
(4)指定スピード(Specified)
の4段階のスピードでタップした場合のログを回収した。
なお、これらのリズムは、3つのリズム、4つのリズム、5つのリズムの3種類に大別することができる。
3つのリズムは、
ABA
AAB
ABB
AB−A
AB−B
AB−C
である。Aを第1の入力、Bを第2の入力とすると、ABAは、まず第1の入力があり、その後に第2の入力があり、その後に第1の入力があると表現できる。また、AB−Aは、まず第1の入力があり、その後に第2の入力があり、相対的に長いその後の第1の入力があると表現できる。AB−Cは、まず第1の入力があり、その後に第2の入力があり、相対的に長いその後の第1の入力及び第2の入力があると表現できる。「相対的に長い」とは、上記の休止期間を意味し、最初の第1の入力と次の第2の入力の間の時間よりも相対的に長いことを意味する。3つ以上のリズムとしては、これら意外にもAA−BやAA−Cもあり、これらを含めてもよい。
4つのリズムは、
ABAB
ABA−A
ABA−C
AB−AB
である。同様に、Aを第1の入力、Bを第2の入力とすると、ABABは、まず第1の入力があり、その後に第2の入力があり、その後に第1の入力があり、その後に第2の入力があると表現できる。また、ABA−Cは、まず第1の入力があり、その後に第2の入力があり、その後に第1の入力があり、相対的に長いその後に第1の入力及び第2の入力があると表現できる。また、AB−ABは、まず第1の入力があり、その後に第2の入力があり、相対的に長いその後に第1の入力があり、その後に第2の入力があると表現できる。
5つのリズムは
ABABA
である。同様に、Aを第1の入力、Bを第2の入力とすると、ABABAは、まず第1の入力があり、その後に第2の入力があり、その後に第1の入力があり、その後に第2の入力があり、その後に第1の入力があると表現できる。
図2及び図3は、実験結果を示す。図2は、Fast, Specified, Preferred, Slowの4段階のスピード毎の、RegularとReverseにおけるタップ期間の長さを示す。それぞれ、
Fast:115.4ms
Specified:139.2ms
Preferred:217.1ms
Slow:391.6ms
であり、利き手から始める場合と非利き手から始める場合とでリズムに大きな変化がないことが分かる。但し、Specifiedに比べてFastの場合及びSlowの場合では、時間的なぶれが大きくなることが分かる。
また、2つのタップに着目し、2つのタップの時間差が46.3ms以内であれば2つのタップは同時にタップされたものとみなすことができ、2つのタップの時間差が47.0ms〜451.3msの範囲内であればこの2つのタップを起点としたリズミカルなタップの可能性ありとみなすことができる。以下、この時間範囲の最小値をSmin、最大値をSmaxとする。また、同時タップとみなせる上限値をDmaxとする。
さらに、休止は長めにとられる傾向にあることも判明した。
一連のタップをリズミカルなタップと判定するためには、以下の基準を満たす必要がある。
基準1:デバイスの妥当性
タップ列T1、T2、T3(図1参照)がリズムABAとなるためには、
device (T1) ≠ device (T2)
device (T1) = device (T3)
である。ここで、device (T)はタップTのデバイス(装置)であることを示す。
基準2:区間列の妥当性
タップ列T1,T2,T3がリズムABAとなるためには、タップAと次のタップBの間の時間をL1、タップBと次のタップAの間の時間をL2として(図1参照)
Smin≦L1≦Smax
L2がリズムABAでのL1をもとにした95%予測区間の中に収まる
ことが必要である。
図3は、リズムABAの場合における、L1とL2の回帰分析結果である。図において、横軸はL1(タップAと次のタップBの間の時間)、縦軸はL2(タップBと次のタップAの間の時間)である。L1=x、L2=yとすると、
y=0.9152x+37.269
=0.8916
が得られる。同様にして、他のリズムの回帰分析を行うと、以下の式が得られる。
リズムAAB:
L2=1.03L1ー7.1
リズムABB:
L2=0.85L1+43.7
リズムABAB:
L2=0.96L1+14.1、L3=0.95L1+10.6
リズムAB−A:
L2=1.54L1+183.0
リズムAB−B:
L2=1.48L1+195.9
リズムAB−C:
L2=1.45L1+207.9
リズムABABA:
L2=0.93L1+22.5、L3=0.97L1−0.5、L4=0.92L1+36.4
リズムABA−A:
L2=0.97L1+28.0、L3=1.54L1+166.5
リズムABA−C:
L2=0.95L1+34.1、L3=1.44L1+170.0
リズムAB−AB:
L2=1.59L1+146.5、L3=0.95L1+0.3
なお、リズムABABにおけるL3は、最初のタップAと次のタップBまでの時間をL1、当該タップBと次のタップAまでの時間をL2、当該タップAから最後のタップBまでの時間をL3とした場合のL3を意味する。同様に、リズムABABAのL4は、2番目のタップBから最後のタップAまでの時間を意味する。一般に、i番目のタップと(i+1)番目のタップの間の時間をLiと表現することができる。
L1をもとにしたL2,L3,L4の95%予測区間は、
y’−t(n−p−1,0.975)*SE≦y≦y’+t(n−p−1,0.975)*SE
である。ここで、y’はyの予測値であり、上記の各リズム毎に得られる回帰分析結果から算出される。SEは回帰分析で得られた標準偏差である。t(n−p−1,0.975)は自由度n−p−1のt分布の0.975パーセンタイル(全体を100として小さい方から数えて何番目になるのかを示す数値)であり、nは観測データの標本数、pは説明変数の数でこの場合は1である。
いま、リズムABA−Cを例にとる。図4は、タップ列T1,T2,T3,T4,T5を模式的に示す。まず利き手でタップT1、次にL1後に非利き手でタップT2、次にL2後に利き手でタップT3、最後のL3後に両手でタップT4,T5を行う。両手でタップT4,T5をする場合の時間差をL4とする。これらのタップ列T1,T2,T3,T4,T5がリズムABA−Cと判断されるためには、
基準1:デバイスの妥当性
device (T1) ≠ device (T2)
device (T1) = device (T3)
device (T4) ≠ device (T5)
かつ、
device (T1) = device (T4) またはdevice (T1) = device (T5)
基準2:第1区間の妥当性
Smin≦L1≦Smax
基準3:第2区間の妥当性
リズムABA−CにおけるL1をもとにしたL2の95%予測区間を[min2,max2]とすると、タップT3が区間[T2+min2,T2+max2]内に収まる。
基準4:第3区間の妥当性
リズムABA−CにおけるL1をもとにしたL3の95%予測区間を[min3,max3]とすると、タップT4が区間[T3+min3,T3+max3]内に収まる。
基準5:第4区間の妥当性
これは同時タップの妥当性であり、
0≦L4≦Dmax
以上のような基準で、任意のタップ列を特定のリズムと判断する。そして、複数のリズムの中で、特に判断し易い、言い換えれば誤検出の少ないリズムがあればそれを選択し、複数のデータ通信装置間でデータ送受信を行うためのトリガとなるリズムとして選定し得る。
図5は、ユーザ数(person)を1人、5人、10人、20人と変動させ、各リズムとなるように装置をタップした場合の、各リズムの誤検出の頻度を示す。5日間の合計誤検出頻度である。例えば、ユーザ数が10人の場合において、
ABAB→1
AB−C→0
ABABA→0
ABA−A→0
ABA−C→0
AB−AB→0
であり、これらのリズムはほぼ確実かつ正確に判定できることが分かる。従って、これらのリズムを用いることで、確実かつ正確にデータ通信装置間のデータ送受信を確立し得る。一般に、タップ数を4以上とすることで、誤検出の頻度を著しく低減し得る。
このようにして誤検出頻度の少ないリズムを選択し、選択したリズムを用いて複数の装置間のデータ通信を許可する。
複数の装置は、同一利用者が使用するものでもよいし、それぞれの装置を異なる利用者が使用するものでもよい。前者の場合、同一人が複数の装置を所有し、利き手で一方の装置をタップし、非利き手で他方の装置をタップして両装置間でのデータ通信を許可する。後者の場合、それぞれの利用者が利き手あるいは非利き手で自己の装置をタップすることで両装置間でのデータ通信を許可する。
次に、本実施形態について、より具体的に説明する。
<第1実施形態>
図6は、本実施形態のシステム構成図を示す。システムは、サーバクライアントシステムである。2つのクライアント端末(以下、これをクライアントと称する)10a、10bが通信回線を介してサーバ12に接続される。クライアント10aは、情報処理装置であって第1端末として機能し、クライアント10bは、情報処理装置であって第2端末として機能する。また、サーバ12は情報管理装置として機能する。
クライアント10a、10bは、それぞれデバイス登録手段、イベント取得手段、コマンド受付手段、メッセージ送信手段、及びメッセージ受信手段を備える。
デバイス登録手段は、利用者(ユーザ)からの指示に基づき、クライアントデバイスのデバイス名とデバイスIDを取得し、サーバ12に送信する。
イベント取得手段は、入力を受け付ける入力手段として機能し、クライアントで生じた入力(イベント)を取得し、デバイスIDとイベントの種類をサーバ12に送信する。本実施形態における入力はタップであり、イベント取得手段は具体的にはタッチパネルで構成され得る。
コマンド受付手段は、サーバ12側のコマンド管理手段からコマンドを受け取り、コマンドに対応するメッセージを送付先のデバイス(クライアント)に送信する。
メッセージ送信手段は、コマンド受付手段の指示に基づき、メッセージを生成し、送信先のデバイス(クライアント)にメッセージを送信する。
メッセージ受信手段は、他のデバイス(クライアント)からメッセージを受け取り、当該メッセージに応じた処理を実行する。
他方、サーバ12は、デバイス管理手段、イベント管理手段、リズムタップ検出手段、コマンド管理手段を備えるとともに、データベース(DB)として、デバイステーブルDB121、イベントテーブルDB122、リズムテーブルDB123、及びコマンドテーブルDB124を備える。
デバイス管理手段は、クライアント10a、10bのデバイス登録手段から送信されたデバイス名とデバイスIDをデバイステーブルDB121に登録する。
イベント管理手段は、クライアント10a、10bのイベント取得手段から送信されたデバイスIDとイベント時刻をイベントテーブルDB122に登録する。
リズムタップ検出手段は、イベントテーブルDB122に新たなイベントが追加される毎に、新たなリズムタップが生じているか否かを判定してリズムタップを検出する。リズムタップ検出手段は、リズムテーブルDB123に格納されたリズムテーブルを参照することでタップ列の区間の妥当性を判定することでリズムタップを検出する。
コマンド管理手段は、クライアント間のデータ通信を許可する許可手段として機能し、リズムタップ検出手段でリズムタップを検出した場合に、クライアント10a、10bにメッセージ送信のコマンド指示を送信する。リズムによって送信するコマンドの種類が異なるため、コマンドテーブルDB124に格納されたコマンドテーブルを参照することで、検出したリズムタップに対応するコマンド指示を送信する。
以下、各部の処理について詳細に説明する。
サーバ12のデバイス管理手段は、クライアント10a、10bのデバイス登録手段から受け取ったデバイス名とデバイスIDをデバイステーブルDB121に登録するが、最も簡易な構成は、デバイスIDのリストである。具体的には、ID=1→クライアント10a、ID=2→クライアント10b、・・・等である。
デバイスの登録にはいくつかの方法がある。ダイアログやファイル等で指定してもよいし、複数のクライアントで会議を行う際に、会議開始時にNFCでかざす等の方法でユーザ登録と兼用でデバイス登録を行ってもよい。このとき、デバイスの登録は会議中のみ有効とし、会議終了後にデバイス登録を解除するのが望ましい。
サーバ12のイベント管理手段は、クライアント10a、10bでイベントが発生したことを検知すると、デバイスIDとイベントの種類、及びイベントの受取時刻をイベントテーブルDB122に登録する。クライアント10a、10bのイベント取得手段から送信されるデバイスIDとイベントの種類は、例えば
デバイス:2
イベント:プレス(press)
である。
図7は、イベントテーブルDB122に登録されるイベントテーブルの一例を示す。イベントID、受取時刻、デバイスID、イベントの種類が関連付けて登録される。なお、クライアント10a、10bとサーバ12間の通信には遅延がないものとし、クライアント10a、10bでのイベント発生時刻は無視する。勿論、イベント発生時刻及びイベント受取時刻をともにイベントテーブルDB122に登録してもよい。
サーバ12のリズムタップ検出手段は、イベントテーブルDB122に登録されたイベント列、すなわちタップ列を用いて特定のリズムを検出する。リズムタップ検出のアルゴリズムを、いくつかのリズムを例にとり説明する。
<リズムABABの検出>
図8は、クライアント10a及びクライアント10bでそれぞれタップがあった場合を模式的に示す。図においてAはクライアント10aでのタップ、Bはクライアント10bでのタップを示す。まず、クライアント10aでタップT1があり、次にクライアント10bでタップT2があり、次にクライアント10aでタップT3があり、次にクライアント10bでタップT4があった場合である。タップT1とタップT2の間の時間をL1、タップT2とタップT3の間の時間をL2、タップT3とタップT4の間の時間をL3とする。
これらのタップ列T1,T2,T3,T4がリズムタップABABと判定されるためには、
基準1:デバイスの妥当性
device (T1) ≠ device (T2)
device (T1) = device (T3)
device (T2) = device (T4)
基準2:第1区間の妥当性
Smin≦L1≦Smax
基準3:第2区間の妥当性
リズムABABにおけるL1をもとにしたL2の95%予測区間を[min2,max2]とすると、T3が区間[T2+min2,T2+max2]の中に収まる
基準4:第3区間の妥当性
リズムABABにおけるL1をもとにしたL3の95%予測区間を[min3,max3]とすると、T4が区間[T3+min3,T3+max3]の中に収まる
との基準を満たすか否かを判定する。ここで、Smin、Smax、min2、max2、min3、max3は、予めリズムテーブルDB123に登録しておく。あるいは、これらの値をL1から回帰分析結果を用いて算出してもよい。
図9は、リズムテーブルDB123に格納されるリズムテーブルの一例を示す。リズム毎に、回帰分析結果(線形回帰)の傾き、切片、t、SEの値が関連付けて登録される。これらのパラメータは、各リズムにおいて、L1をもとにしてL2,L3,L4の95%予測区間の下限と上限を算出するのに必要なパラメータである。例えば、リズムABAにおけるL2の95%予測期間の下限min2及び上限max2は、
min2=0.91*L1+37.2−1.96*1676
max2=0.91*L1*37.2+1.96*1676
と算出される。なお、リズムABA−Cでは、4番目のタップがクライアント10aとクライアント10bの同時タップであり、この場合には便宜上、全ての値を0として登録しておく。
検出アルゴリズムは以下の通りである。
ABABの有効な部分タップ列の集合をRABABとする。有効な部分タップ列とは、デバイスの妥当性と区間の妥当性の両条件を満足する部分タップ列である。
タップTが生じたとき、RABABの全ての要素rに対して、
r=1のとき(r=T1)
Smin≦T−T1(=L1)≦Smaxのとき、device (T1)≠device(T)であればrをT1Tで置き換える。他方、Smax<T−T1(=L1)のときは、rをRABABから削除する。
r=2のとき(r=T1T2)
min2≦T−T2(=L2)≦max2のとき、device (T1)=device (T)であればrをT1T2Tで置き換える。他方、max2<T−T2のときは、rをRABABから削除する。
r=3のとき(r=T1T2T3)
min3≦T−T3(=L3)≦max3のとき、device (T2)=device (T)であればT1T2T3Tをリズムタップとして判定する。他方、max3<T−T3のときは、rをRABABから削除する。
以上の処理を全ての要素rに対して繰り返し実行することで、タップ列T1,T2,T3,T4がリズムABABであるか否かを判定する。
<リズムAB−Cの検出>
図10は、クライアント10a及びクライアント10bでそれぞれタップがあった場合を模式的に示す。図においてAはクライアント10aでのタップ、Bはクライアント10bでのタップを示す。まず、クライアント10aでタップT1があり、次にクライアント10bでタップT2があり、次にクライアント10b及びクライアント10aでほぼ同時にタップT3、T4があった場合である。タップT1とタップT2の間の時間をL1、タップT2とタップT3の間の時間をL2、タップT3とタップT4の間の時間をL3とする。
これらのタップ列T1,T2,T3,T4がリズムタップAB―Cと判定されるためには、
基準1:デバイスの妥当性
device (T1) ≠ device (T2)
device (T3) ≠ device (T4)
かつ、
device (T1) = device (T3)またはdevice (T1) = device (T4)
基準2:第1区間の妥当性
Smin≦L1≦Smax
基準3:第2区間の妥当性
リズムAB―CにおけるL1をもとにしたL2の95%予測区間を[min2,max2]とすると、T3が区間[T2+min2,T2+max2]の中に収まる
基準4:第3区間の妥当性
0≦L3≦Dmax
との基準を満たすか否かを判定する。Smin、Smax、min2、max2、Dmax、予めリズムテーブルDB123に登録しておく。あるいは、これらの値をL1から回帰分析結果を用いて算出してもよい。
検出アルゴリズムは以下の通りである。
r=1のとき(r=T1)
Smin≦T−T1(=L1)≦Smaxのとき、device (T1)≠device(T)であればrをT1Tで置き換える。他方、Smax<T−T1(=L1)のときは、rをRABABから削除する。
r=2のとき(r=T1T2)
min2≦T−T2(=L2)≦max2のとき、device (T1)=device (T)またはdevice(T2)=device(T)であればrをT1T2Tで置き換える。他方、max2<T−T2のときは、rをRABABから削除する。
r=3のとき(r=T1T2T3)
0≦T−T3≦Dmaxのとき、device (T1)=device (T)またはdevice (T2)=device (T)
であればT1T2T3Tをリズムタップとして判定する。他方、Dmax<T−T3のときは、rをRABABから削除する。
以上の処理を全ての要素rに対して繰り返し実行することで、タップ列T1,T2,T3,T4がリズムAB−Cであるか否かを判定する。
なお、複数のリズムタップが同時に検出される場合があり得る。例えば、リズムABAとリズムABABA等である。このような場合、予めどちらのリズムを優先させるかプライオリティを決めておけばよい。リズムの長い方を優先する等である。リズムの長い方が発生確率が低く、その分だけ確実性が向上するからである。
図11は、特定のリズムを検出した場合の処理を模式的に示す。サーバ12のりズムタップ検出手段でリズムタップを検出すると、コマンド管理手段は、検出されたリズムタップに対応するコマンドをコマンドテーブルDB124から読み出す。コマンド管理手段は、読み出したコマンド(検出したリズムに対応するコマンド)をクライアント10aのコマンド受付手段に送信する。クライアント10aのメッセージ送信手段は、クライアント10bにメッセージを送信する。クライアント10bのメッセージ受信手段は、受信したメッセージに応じた処理を実行する。
図12は、コマンドテーブルDB124に格納されるコマンドテーブルの一例を示す。リズムとコマンドが対応付けて記憶される。例えば、
リズムABA:TextSend
リズムAAB:FileSend
等である。ここで、コマンドは、リズムが検出されたクライアント10aとクライアント10bの間で実行されるべきコマンドである。また、コマンドは、検出されたリズムの最初のタップT1を実行したクライアントに送信される。
例えば、リズムAAB検出された場合、コマンドはFileSend(アクティブファイルの送信)であり、最初のタップT1はクライアント10aで実行されているから、コマンド管理手段はクライアント10aに対して、「クライアント10bにファイルを送信する」旨のコマンドを送信する。なお、FileSendコマンドはアクティブファイルの送信を意味するコマンドであり、ファイルの送信先はBであるタップT3のデバイスであるクライアント10bを指定する。
クライアント10aでは、コマンド受付手段がサーバ12からのコマンドを受け取り、メッセージ送信手段がクライアント10bにメッセージとファイルを送信する。クライアント10bでは、メッセージ受信手段がメッセージを受け取り、メッセージの種類に応じた処理を行う。例えば、受信したファイルをクライアント10bのディスプレイに表示する。
なお、複数種類のリズムに対してリズムタップを検出する場合、基本的にはリズムごとに異なるアルゴリズムを同時並行的に実行することになる。判定基準やパラメータがリズムごとに異なるからである。例えば、3種類のリズムABA、ABB、ABABを検出する場合、サーバ12がタップTのイベントをクライアント10a、10bから受信すると、ABA、ABB、ABABの3種類の検出アルゴリズムを全て並列実行する。この際、異なるリズムのリズムタップが同時に検出されることもあり得るので、既述したようにどれを優先するかを事前に決めておくことが望ましい。優先順位順に検出アルゴリズムを実行し、リズムタップが検出された段階でタップTに対するリズムタップ検出を終了してもよい。
また、同じタップから始まる異なるリズムが検出される可能性もある。例えば、ABAとABABである。ABABはABAの延長に該当する。長いタップ列の検出を優先する場合において、ABAが検出された段階ですぐにABAが検出されたと判断してはならない。ABAが検出された後、少し待って、ABABが検出されないことを確認した上でABAが検出されたと判断する必要がある。すなわち、ABABが検出されなかったことによって、タップされたのはABAであったと判定する。ABAが検出された時点でABAを仮判定し、その後にABABが検出されなかったことをもって仮判定したABAを本判定するということもできる。
<第2実施形態>
図13は、本実施形態のシステム構成図を示す。システムは、2つのクライアント10a、10bが互いに通信するピア・ツー・ピア(Peer to Peer:P2P)構成である。クライアント10a、10bは、ともに情報処理装置として機能する。
クライアント10a,10bは、それぞれ、イベント取得手段、リズムタップ判定手段、メッセージ送信手段、メッセージ受信手段を備え、データベース(DB)として、リズムテーブルDB及びコマンドテーブルDBを備える。図において、クライアント10aのリズムテーブルDB、コマンドテーブルDBをリズムテーブルDB10a1、コマンドテーブルDB10a2と示し、クライアント10bのリズムテーブルDB、コマンドテーブルDBをリズムテーブルDB10b1、コマンドテーブルDB10b2と示す。
クライアント10a,10bのイベント取得手段は、クライアント10a,10bで生じたイベントを取得し、イベントメッセージを他のクライアントにブロードキャスト送信する。
クライアント10a,10bのリズムタップ判定手段は、有効な複数のイベントメッセージに対して、リズムタップ判定の継続/受理/却下を判定する。判定には、リズムテーブルDB10a1、10b1を参照する。
「継続」であれば、対応するクライアントにイベントメッセージを送信する。
「受理」であれば、コマンドテーブルDB10a2,10b2を参照して、メッセージ送信手段に依頼して、対応するコマンドを対応するクライアントに送信する。
「却下」であれば、他のクライアントとのイベントメッセージのやり取りを中止する。
クライアント10a,10bのメッセージ送信手段は、コマンドに基づきメッセージを生成して送信先のクライアントにメッセージを送信する。
クライアント10a,10bのメッセージ受信手段は、他のクライアントからメッセージを受け取り、当該メッセージに応じた処理を実行する。
なお、イベント取得手段の機能は、基本的には第1実施形態と同様であるが、イベントメッセージを送るのはサーバ12ではなく、他のクライアント全てにブロードキャストする点に留意すべきである。従って、例えばクライアント10a,10bに加えてさらにクライアント10c,10d,・・・が存在する場合において、クライアント10aのイベント取得手段は、取得したイベントを他の全てのクライアント10b,10c,10d,・・・に送信する。
図14は、クライアント間でブロードキャスト送信されるイベントメッセージのデータ構造を示す。
SubSequenceは、リズムタップの部分列であり、それまでの部分列がデバイス妥当性と区間妥当性を満足するものである。すなわち、その後にいくつかタップ列を追加するとリズムタップになる可能性があるタップ列である。Candidatesは、部分タップ列が満足するリズム候補の集合である。最初の段階は、たくさんのリズム候補があり得るが、部分タップ列が長くなるに従い、リズム候補集合は絞り込まれていく。
FirstIntervalは、T2―T1でも算出され得るが、異なるクライアントで時計が合っていない可能性があるので、同じクライアントでのタップの時間差、あるいはdevice(T2)でのタップ時刻と到着時刻の差を第1区間長として利用する。
ArrivalTimeは、イベントメッセージの送信のタイミングでは空欄であり、メッセージを受け取った側で到着時刻が記録される。
図15は、クライアント間でのイベントメッセージのやり取りを示すシーケンス図であり、例としてリズムABABの場合を示す。
クライアント10aにおけるタップ列をT1a、T3aで示し、クライアント10bにおけるタップ列をT2b、T4bで示す。時刻T1aでタップT1aが検出されると、クライアント10aのイベント取得手段はこれを検出して、
SubSequence : T1a
Candidates : ABAB
FirstInterval :
ArrivalTime :
というイベントメッセージを他のクライアントにブロードキャストする。本実施形態では、クライアント10a,10bを想定しているから、クライアント10bに送信する。クライアント10bでは、時刻T1bに当該イベントメッセージが到着したとする。
次に、時刻T2bでタップT2bが検出されると、クライアント10bのイベント取得手段はこれを検出して、
SubSequence : T1aT2b
Candidates : ABAB
FirstInterval : T2b-T1b (= L1)
ArrivalTime :
というイベントメッセージを他のクライアントにブロードキャストする。本実施形態では、クライアント10aに送信する。ここで、クライアント10bのリズムタップ判定手段は、T2b−T1bを算出し、これが区間[Smin,Smax]に収まれば「継続」と判定してクライアント10aにイベントメッセージを送信する。また、リズム候補は、複数存在する場合に可能性のあるもの全てを送信する。クライアント10aでは、時刻T2aに当該イベントメッセージが到着したとする。
次に、時刻T3aでタップT3aが検出されると、クライアント10aのイベント取得手段はこれを検出して、
SubSequence : T1aT2bT3a
Candidates : ABAB
FirstInterval : L1
ArrivalTime :
というイベントメッセージをクライアント10bに送信する。ここで、クライアント10aのリズムタップ判定手段は、T3a−T2bを算出し、これが区間[min2,max2]に収まり、かつ、device (T1a)=device (T3a)であれば「継続」と判定し、クライアント10bにイベントメッセージを送信する。クライアント10bでは、時刻T3bに当該イベントが到着したとする。
次に、時刻T4bでタップT4bが検出されると、クライアント10bのイベント取得手段はこれを検出する。また、クライアント10bのリズムタップ判定手段は、T4b−T3bを算出し、これが区間[min3,max3]に収まり、かつ、device (T1a)≠device (T4a)であれば、リズムタップABABを検出し、「受理」と判定する。クライアント10bのリズムタップ判定手段は、コマンドテーブルDB10b2を参照してメッセージ送信手段に依頼し、対応するコマンドをクライアント10aに送信する。クライアント10aのメッセージ受信手段は、クライアント10bからのコマンドを受信し、対応する処理を実行する。対応する処理は、例えばファイルのクライアント10bへの送信等である。
リズムタップ判定手段における詳細なアルゴリズムは、次の通りである。
クライアントがイベントメッセージEを受け取った場合、すぐに、当該イベントメッセージEのArrivalTimeに到着時刻を記録する。
クライアントでイベント、例えばPressイベントが生じた場合、クライアントが保持する全てのイベントメッセージに対して、以下を実行する。
イベントメッセージのSubSequenceの長さが1のとき(T1)、T1の到着時刻をT1*とすると、Smin≦T−T1*≦SmaxであればイベントメッセージEのSubSequenceをT1Tに置き換える。また、FirstIntervalをT−T1*に設定する。また、イベントメッセージをdevice(T1)のクライアントに送信する。他方、Smax<T−T1*のとき、イベントメッセージをイベントメッセージ集合から削除する。
イベントメッセージのSubSequenceの長さが2のとき(T1T2)、T2の到着時刻をT2*とする。イベントメッセージのFirstInteravalをL1とすると、min2≦T−T2*≦max2,device(T1)=device(T)のとき、イベントメッセージのSubSequenceをT1T2Tに置き換える。また、イベントメッセージをdevice(T2)のクライアントに送信する。他方、Smax<T−T2*のとき、イベントメッセージをイベントメッセージ集合から削除する。
イベントメッセージのSubSequenceの長さが3のとき(T1T2T3)、T3の到着時刻をT3*とする。イベントメッセージのFirstIntervalをL1とすると、min3≦T−T3*≦max3、かつdevice(T2)=device(T)のとき、リズムタップT1T2T3を検出する。他方、Smax<T−T2*のとき、イベントメッセージをイベントメッセージ集合から削除する。
このように、本実施形態では、複数のクライアントで時刻合わせをする必要はない。各クライアントで時刻データを送信する必要もない。但し、時刻データを送信することで、イベントが戻ってきたときに、通信遅延を算出することができ、緻密な区間推定ができる利点がある。
また、本実施形態では、サーバ12で集中管理するわけではないので、リズムに関する知識やリズム毎の区間推定方法は、各クライアントで保持する必要がある。また、アルゴリズムを変更する場合、サーバ12のバージョンアップだけでは対応できず、全てのクライアントのソフトウェアを入れ替える必要がある。
<第3実施形態>
第2実施例のピア・ツー・ピア構成では、イベントごとに他の全てのクライアントにイベントメッセージをブロードキャスト送信するので、ネットワークのトラフィックが増大する可能性がある。
これを避けるため、本実施形態では、イベント列がある程度まとまってから、それを他のクライアントにブロードキャスト送信し、受け取ったクライアント側で送られたイベント列と照合し、自分のイベント列と組み合わせた場合に全体としてリズムタップになるか否かを判定する。単独イベントごとにメッセージをブロードキャスト送信するのではなく、複数のイベントからなるイベント列を送信することでネットワークトラフィックを低減できる。また、イベント発生ごとにメッセージを送信するのではなく、イベント列がある一定条件を満たしたときのみメッセージを送信するためネットワークトラフィックを低減できる。
図16は、クライアント10a,10bでのタップ列の一例を模式的に示す。ABA−Cのリズムタップの場合であり、タップ列T1,T3,T4はクライアント10aで発生し、タップ列T2,T5はクライアント10bで発生したものとする。
リズムタップのタップ列のうち、クライアント10a(先にタップされるクライアント)で生じる部分列を「先頭片側部分列」(T1T3T4)、クライアント10b(後にタップされるクライアント)で生じる部分列を「後方片側部分列」(T2T5)とする。
あるクライアントで発生したイベント列がリズムタップの先頭片側部分列として認められた場合(タップ列の区間幅が特定のリズムの先頭片側部分列としてもっともらしい場合)、クライアントは他のクライアントに先頭片側部分列をブロードキャストする。これを受け取ったクライアントでは、送られたタップ列と自分のタップ列を組み合わせた場合に、リズムタップになるか否かを判定する。
本実施形態におけるシステム構成は、第2実施形態の構成とほぼ同様であるが、各クライアントにさらに、イベント保持手段と部分列判定手段を備える。
イベント取得手段は、第2実施形態と同様に、クライアントで生じたイベントを取得し、イベントを他のクライアントにブロードキャスト送信する。
イベント保持手段は、一定時間だけイベントを保持する。
部分列判定手段は、イベントテーブルのイベント列から特定のリズムの先頭片側部分列を探索する。見つかったら、それを他のクライアントにブロードキャストする。
リズムタップ判定手段は、他のクライアントから先頭片側部分列を受け取ったら、それを自分のイベントテーブルのイベント列と照合して、両者を組み合わせてリズムタップになるか否かを判定する。リズムタップが検出された場合、コマンドテーブル10a2,10b2を参照して、メッセージ送信手段に依頼して、対応するコマンドを対応するクライアントに送信する。
図17は、イベント保持手段で保持されるイベントテーブルの一例を示す。イベントIDと時刻が関連付けて記憶される。イベント取得手段で取得されたイベントは、順次、イベントテーブルに格納される。一定時間Tmaxが経過したイベントは、それ以上保持していても、先頭片側部分列を構成することもないし、送付された先頭片側部分列と組み合わせてもリズムタップを構成するわけではないので、テーブルから削除する。Tmaxは、以下のように算出される。
すなわち、まず、先頭の区間で最大値のSmaxを選択する。次に、これをL1としてL2の推定値の最大値を選択する。このようにして、次々とL3,L4の最大値も選択し、最大のタップ数に関してこれらを全て加算した値をTmaxとする。
図18及び図19は、部分列判定手段における処理を模式的に示す。いま、図18に示すような、ABABのリズムタップが存在したとする。
タップT1,T3だけから、タップT2,T4の存在なしに、タップT1,T3が先頭片側部分列を構成するか否かを判定する必要がある。L1の長さがわからないから、L1が最小の場合と最大の場合を想定して、タップT3のタイミングを予想する必要がある。
まず、L1が最小の場合のL2の95%信頼区間の最小値Sminを取得する。次に、L1が最大の場合のL2の95%信頼区間の最小値Smaxを取得する。そして、タップT3が区間[T1+Smin,T1+Smax]に収まれば、T1,T3はリズムABABの先頭片側部分列を構成する可能性があると判定する。
図19は、部分列判定手段が送信するデータ例を示す。部分列判定手段は、リズムの種類(Rhythm)、タップ列(SubSequence)、送信時刻(Time)、及びデバイス(Device)を送信する。
リズムABABの判定方法は、以下の通りである。
まず、自分の時刻と送信元のクライアントの時間の差分Diffを算出し、これを自分と送信元クライアントのシステム時計の時間差とする。
次に、自分のイベントテーブルのイベントT2でT2−T1+Diffが区間[Smin,Smax]に収まるT2を探索する。
次に、T2−T1+DiffをL1とする。
次に、リズムABABにおけるL1をもとにしたL2の95%予測区間を[min2,miax2]とし、T3+Diffが区間[T2+min2,T2+max2]に収まるか否かを判定する。
次に、リズムABABにおけるL1をもとにしたL3の95%予測区間を[min3,max3]とし、T4+Diffが区間[T3+min3,T3+max3]に収まるか否かを判定する。
なお、部分列判定手段は、リズム毎に先頭片側部分列を検出するから、同じタップ列から複数のリズムの先頭片側部分列が検出される可能性がある。この場合、検出されたリズムの数だけ、他のクライアントにブロードキャスト送信すればよい。
最後に、タップ列T1,T2,T3,T4がリズムタップABABと判定されるための基準は以下の通りである。
基準1:デバイスの妥当性
device(T1)≠device(T2), device(T1)=device(T3), device(T2)=device(T4)
基準2:第1区間の妥当性
Smin≦L1≦Smax
基準3:第2区間の妥当性
リズムABABにおけるL1をもとにしたL2の95%予測区間を[min2,max2]とすると、T3が区間[T2+min2,T2+max2]に収まる
基準4:第3区間の妥当性
リズムABABにおけるL1をもとにしたL3の95%予測区間を[min3,max3]とすると、T4が区間[T3+min3,T3+max3]に収まる
ここで、min2,max2,min3,max3等は、リズムテーブルDB10a1,10b1を参照して必要なパラメータを取得し、L1の値を利用することにより算出される。
以上、本発明の実施形態について説明したが、これらの実施形態におけるクライアントは、スマートフォン、タブレット端末、パーソナルコンピュータ等の任意の情報端末を用いることができる。また、各実施形態におけるクライアントの機能ブロックは、CPUがROMやSSD、HD等のプログラムメモリに記憶された処理プログラムを読み出し、RAMをワーキングメモリとして用いて順次実行することで実現される。サーバ12の機能ブロックについても同様である。
サーバクライアントシステムにおけるサーバのCPUが処理プログラムにより実行する主な機能を列挙すると次の通りである。
(1)複数のクライアント(端末)でなされた3以上の入力の順序と時間間隔を取得する。
(2)取得した順序と時間間隔が、所定パターンに一致するか否かを判定する。
(3)一致する場合に、複数のクライアントの間で所定パターンに対応するコマンドを実行するようにコマンドを送信する。
また、ピア・ツー・ピアシステムにおけるクライアントのCPUが処理プログラムにより実行する主な機能を列挙すると次の通りである。
(1)入力がなされると、当該入力を他のクライアントに対してブロードキャスト送信する。
(2)複数のクライアント(端末)でなされた3以上の入力の順序と時間間隔を取得する。
(3)取得した順序と時間間隔が、所定パターンに一致するか否かを判定する。
(4)一致する場合に、複数のクライアントの間で所定パターンに対応するコマンドを実行するようにコマンドを送信する。
なお、クライアントの機能の一部は、プログラムの実行によるソフトウェア処理ではなく、ハードウェア処理により実現してもよい。ハードウェア処理は、例えばASICやFPGA(フィールドプログラマブルゲートアレイ)などの回路を用いて行っても良い。
また、本発明は上記の実施形態に限定されるものではなく、種々の変形が可能である。以下に変形例について説明する。
<変形例1>
実施形態では、データの送受信を行うグループを形成するために、事前登録や会議等でのアドホックな登録を例示したが、この際に、カードリーダを利用する、特殊なリズムの同時タップを利用する、あるいは両者を併用する等を適宜選択できるように構成してもよい。また、ネットワーク構成についても、有線LAN(遅延1ms)、無線LAN(遅延10ms)、Bluetooth(登録商標)(遅延10ms)のいずれを用いてもよい。また、システム時計に関しては、各クライアントでのシステム時刻とネットワーク遅延をサーバ12側で管理しておけば、必ずしもシステム時計を合わせる必要はない。
<変形例2>
実施形態では、PressイベントとReleaseイベントからなるタップを入力として例示したが、これに代えて手のひらによるタップを入力としてもよい。本願発明者等は、手のひらのタップにより誤検出がさらに少なくなることを確認している。
<変形例3>
実施形態では、第1区間や第2区間等の区間妥当性を判定することでリズムを検出しているが、区間妥当性を判定する際の区間の揺らぎの許容度を可変としてもよい。具体的には、速いリズム(fast)及び遅いリズム(Slow)の場合は、そうでない場合に比べて揺らぎの許容度を大きくする等である。具体的には、標準的な速度を基準速度とし、これよりも速いリズム及び遅いリズムでは、基準速度における揺らぎの許容度を大きくする。また、速いリズムの場合、タップ列に逆転現象が生じる可能性があることを考慮して判定してもよい。非常に速くAABとタップすると、実際にはABAとなっても利用者は気づかないことがあるからである。
また、利用者の年齢に応じて区間の揺らぎの許容度を可変としてもよい。相対的に高年齢の利用者の場合は揺らぎの許容度を大きくする等である。利用者の年齢は、クライアントに利用者の年齢や生年月日のデータが記憶されている場合、これらのデータを用いて推定すればよい。
また、複数人で協調してリズムを刻む場合、揺らぎの許容を大きくするように、事前にシステムに指定可能な構成としてもよい。例えば、サーバクライアントシステムにおいて、会議等でのアドホックな登録をする際にサーバ12に揺らぎの許容度を設定する等である。利用者の数が多くなるほど、これに相間させて揺らぎの許容度を大きくしてもよい。
さらに、リズムを正確に刻めずにデータ送受信に失敗した場合に、通常は同じ操作を繰り返すものと想定されるから、その直後は一時的に揺らぎの許容度を大きくしてもよい。具体的には、リトライ回数に応じて揺らぎの許容度を大きくする等である。
<変形例4>
実施形態において、誤動作をさらに少なくするため、サーバクライアントシステム、あるいはピア・ツー・ピアシステムにおいて、所定距離以上離れた位置にあるクライアントの1対1のペアリングは許容しないように構成してもよい。クライアント間の距離は、例えばクライアントがGPS等の位置検出モジュールを備えている場合に、当該モジュールで検出された位置情報を利用することができる。
<変形例5>
実施形態において、リズムの検出にPressの圧力や接触時間、接触面積を用いてもよい。圧力を用いる場合、例えばAのタップとして相対的に強い圧力A1と相対的に弱い圧力A2があり、同様にBのタップとして相対的に強い圧力B1と相対的に弱い圧力B2を設定し、
A1B1A2
A1B2A1
A2B2A1
等の強弱のリズムによってデータ通信を許可する。圧力の強弱は、圧力センサで検出し得る。
また、接触時間を用いる場合、例えばAのタップとして相対的に長い(長押し)タップA1と相対的に短いタップA2があり、同様にBのタップとして相対的に長いタップB1と相対的に短いタップB2を設定し、
A1B1A2
A1B2A1
A2B2A1
等の長短のリズムによってデータ通信を許可する。
<変形例6>
実施形態において、個人の癖を学習し、個人毎に基準をカスタマイズしてもよい。これにより、学習させた個人の使い勝手が向上するとともに、他の利用者の介入による誤動作を防止できる。
<変形例7>
実施形態において、文化的背景により、タップしやすいリズムとそうでないリズムが国や地域によって異なることが想定される。これを利用して、特定の国や地域、あるいは文化圏毎に安全性の高いリズムを選択することができる。
例えば、日本において、337拍子(タンタンタン・タンタンタン・タンタンタンタンタンタンタン)や特定の有名テレビゲームのリズム(ジャジャンジャンジャジャンジャン・トン)等の、タップ数は多いものの、多くの日本人に馴染みの深いタップ列を想定すると、こうした長いリズムが同時刻にたまたま発生する確率は世界中の全デバイスを対象にしても限りなく小さいものと考えられる。従って、複数人でこれらのリズムを刻むことで、一時的なグループを形成させる。なお、こうした行為には、会議の開始時に全員で同じリズムを刻むことで、会議参加者の一体感を高める効果も期待できるという副次的な利点もある。
<変形例8>
実施形態において、一般的に3つのリズムよりも4つのリズム、4つのリズムよりも5つのリズムというように、長いリズムほど偶発的に生じる確率が低く、その分だけ安全性が相対的に向上することを利用し、相対的に長いリズムには相対的に重要度の高い情報を処理するコマンドを割り当て、相対的に短いリズムには相対的に重要度の低い情報を処理するコマンドを割り当ててもよい。具体的には、図12に示すコマンドテーブルDB124に格納されるコマンドテーブルにおいて、リズムの長短に応じて重要度の異なるコマンドを割り当てればよい。
<変形例9>
実施形態では、操作(入力)としてタップを例示したが、タップに代えて端末のシェイク、すなわち加速度の変動としてもよい。この場合、入力は加速度であり、入力手段は加速センサ等を用い得る。あるいは、所定の音声入力としてもよい。
10a,10b クライアント(端末)、12 サーバ、121 デバイステーブルDB、122 イベントテーブルDB、123 リズムテーブルDB、124 コマンドテーブルDB。

Claims (17)

  1. 自装置で行われた操作と他装置で行われた操作との順序及び時間間隔が予め定められた順序及び時間間隔に一致する場合に、自装置と他装置とで、当該順序及び時間間隔に関連付けられた通信を行う通信手段
    を有し、
    前記通信手段は、3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記自装置または前記他装置の利用者の年齢、リトライ回数、前記自装置または前記他装置の利用者の数のいずれかに応じて可変する、
    情報処理装置。
  2. 予め定められた順序及び時間間隔は複数存在し、
    前記通信手段は、3以上の操作の順序と操作間の時間間隔とが一致する予め定められた順序及び時間間隔に応じたデータ通信を行う
    請求項1に記載の情報処理装置。
  3. 前記通信手段は、3以上の操作の順序と操作間の時間間隔とが一致する予め定められた順序及び時間間隔が複数存在する場合にいずれかのパターンを他のパターンに優先させてデータ通信を行う
    請求項2に記載の情報処理装置。
  4. 前記通信手段は、操作数の多い予め定められた順序及び時間間隔を優先させてデータ通信を行う
    請求項3に記載の情報処理装置。
  5. 予め定められた順序及び時間間隔は、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作を含む第1パターンと、
    自装置の操作と、その後の自装置の操作と、その後の前記他装置の操作を含む第2パターンと、
    自装置の操作と、その後の前記他装置の操作と、その後の前記他装置の操作を含む第3パターンと、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置及び前記他装置の操作を含む第4パターン
    の少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置。
  6. 予め定められた順序及び時間間隔は、
    自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置の操作を含む第1パターンと、
    自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の前記他装置の操作を含む第2パターンと、
    自装置の操作と、その後の自装置の操作と、相対的に長いその後の前記他装置の操作を含む第3パターンと、
    自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置及び前記他装置の操作を含む第4パターンと、
    の少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置。
  7. 予め定められた順序及び時間間隔は、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、その後の前記他装置の操作を含む第1パターンと、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の自装置の操作を含む第2パターンと、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の前記他装置の操作を含む第3パターンと、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、相対的に長いその後の自装置及び前記他装置の操作を含む第4パターンと、
    自装置の操作と、その後の前記他装置の操作と、相対的に長いその後の自装置の操作と、その後の前記他装置の操作を含む第5パターン
    の少なくともいずれかを含む請求項2〜4のいずれかに記載の情報処理装置。
  8. 予め定められた順序及び時間間隔は、
    自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作と、その後の前記他装置の操作と、その後の自装置の操作を含む請求項2〜4のいずれかに記載の情報処理装置。
  9. 予め定められた順序及び時間間隔は、自装置及び前記他装置の、相対的に強い操作及び相対的に弱い操作を含む請求項5〜8のいずれかに記載の情報処理装置。
  10. 予め定められた順序及び時間間隔は、自装置及び前記他装置の、相対的に長い操作及び相対的に短い操作を含む請求項5〜8のいずれかに記載の情報処理装置。
  11. 前記通信手段は、前記許容度を、3以上の操作の速度が基準速度よりも遅い場合に相対的に大きくする請求項1〜10のいずれかに記載の情報処理装置。
  12. 前記通信手段は、前記利用者の年齢が高いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置。
  13. 前記通信手段は、前記リトライ回数が多いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置。
  14. 前記通信手段は、前記利用者の数が多いほど前記許容度を大きくする請求項1〜10のいずれかに記載の情報処理装置。
  15. 前記通信手段は、操作数の相対的に多いパターンと一致した場合には、操作数の相対的に少ないパターンと一致した場合に比べて、相対的に重要度の高いデータ通信を行う請求項2に記載の情報処理装置。
  16. 第1装置で行われた操作と第2装置で行われた操作との順序及び時間間隔が予め定められた順序及び時間間隔とに一致する場合に、前記第1装置と前記第2装置とで、当該順序及び時間間隔とに関連付けられた通信を行わせる制御手段
    を有し、
    前記制御手段は、3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記第1装置または前記第2装置の利用者の年齢、リトライ回数、前記第1装置または前記第2装置の利用者の数のいずれかに応じて可変する、
    情報管理装置。
  17. コンピュータに、
    第1装置での操作を取得するステップと、
    第2装置での操作を取得するステップと、
    前記第1装置及び前記第2装置から取得した操作の順序と操作間の時間間隔とが予め定められた順序及び時間間隔とに一致する場合に、前記第1装置と前記第2装置とで、当該予め定められた順序及び時間間隔とに関連付けられたデータ通信を行わせるステップと、
    3以上の操作の順序と操作間の時間間隔とが所定パターンに一致する場合の許容度を、前記3以上の操作の速度、前記第1装置または前記第2装置の利用者の年齢、リトライ回数、前記第1装置または前記第2装置の利用者の数のいずれかに応じて可変するステップと、
    を実行させるプログラム。
JP2016173140A 2016-09-05 2016-09-05 情報処理装置、情報管理装置、及びプログラム Active JP6790613B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2016173140A JP6790613B2 (ja) 2016-09-05 2016-09-05 情報処理装置、情報管理装置、及びプログラム
US15/596,335 US10326716B2 (en) 2016-09-05 2017-05-16 Information processing device and information management device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2016173140A JP6790613B2 (ja) 2016-09-05 2016-09-05 情報処理装置、情報管理装置、及びプログラム

Publications (2)

Publication Number Publication Date
JP2018041172A JP2018041172A (ja) 2018-03-15
JP6790613B2 true JP6790613B2 (ja) 2020-11-25

Family

ID=61280985

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016173140A Active JP6790613B2 (ja) 2016-09-05 2016-09-05 情報処理装置、情報管理装置、及びプログラム

Country Status (2)

Country Link
US (1) US10326716B2 (ja)
JP (1) JP6790613B2 (ja)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4347827A (en) * 1981-06-01 1982-09-07 Motorola, Inc. Noise blanker circuit for use with electronic ignition systems or the like
US4855894A (en) * 1987-05-25 1989-08-08 Kabushiki Kaisha Kenwood Frequency converting apparatus
JP3900605B2 (ja) 1997-07-30 2007-04-04 ソニー株式会社 データ送信/受信/送受信装置、データ伝送システム、及び、データ送信/受信/送受信/伝送方法
JP4816701B2 (ja) 2000-10-24 2011-11-16 ソニー株式会社 情報処理装置
US7002553B2 (en) * 2001-12-27 2006-02-21 Mark Shkolnikov Active keyboard system for handheld electronic devices
JP4329388B2 (ja) 2003-04-22 2009-09-09 ソニー株式会社 データ通信システム、データ通信装置及びデータ通信方法、並びにコンピュータ・プログラム
GB0703276D0 (en) * 2007-02-20 2007-03-28 Skype Ltd Instant messaging activity notification
US8156275B2 (en) * 2009-05-13 2012-04-10 Apple Inc. Power managed lock optimization
KR101749992B1 (ko) * 2009-11-13 2017-06-23 삼성전자주식회사 시간 범위를 이용한 위치정보 제공방법
JP2012129979A (ja) * 2010-11-24 2012-07-05 Jvc Kenwood Corp 区間作成装置、区間作成方法、及び区間作成プログラム
TWI557528B (zh) * 2014-10-03 2016-11-11 円星科技股份有限公司 電壓產生電路

Also Published As

Publication number Publication date
US10326716B2 (en) 2019-06-18
US20180069812A1 (en) 2018-03-08
JP2018041172A (ja) 2018-03-15

Similar Documents

Publication Publication Date Title
EP3762920B1 (en) Identification and processing of commands by digital assistants in group device environments
US10601739B2 (en) Smart messaging for computer-implemented devices
CN111656439B (zh) 基于延迟控制电子设备的方法、电子设备及存储介质
CN110021300B (zh) 数字助理服务的远场延伸
EP2998822B1 (en) Mobile communication device using a plurality of wearable devices in parallel
US8849934B2 (en) Instant messaging activity notification
TWI229787B (en) System and method for automatic control device personalization
US8880495B2 (en) Search query expansion and group search
US20160292269A1 (en) Apparatus for recognising and indexing context signals on a mobile device in order to generate contextual playlists and control playback
JP2013167806A (ja) 情報通知支援装置、情報通知支援方法、および、プログラム
WO2021080801A1 (en) Personalized updates upon invocation of a service
KR20190016671A (ko) 통신 장치, 서버 및 통신 방법
JP2018077590A (ja) サーバ装置
JP6462438B2 (ja) 会話相手マッチング装置、会話相手マッチングシステムおよび会話相手マッチング用プログラム
JP6790613B2 (ja) 情報処理装置、情報管理装置、及びプログラム
JP6250871B2 (ja) メッセージ送信方法、装置、プログラム及び記録媒体
CN117609618B (zh) 职位信息的推荐方法、装置、电子设备及存储介质
CN101930297A (zh) 用于网络交互中供用户进行文字输入的方法、设备和系统
CN117764545A (zh) 职位信息的处理方法、装置、电子设备及存储介质
JP2009054054A (ja) 共通属性情報検索装置、共通属性情報検索方法、及び共通属性情報検索プログラム
WO2022142427A1 (zh) 好友添加方法、装置、设备及存储介质
JP5876621B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP2001290789A (ja) 通信手段選択支援装置及び方法
JP6497117B2 (ja) コミュニケーション制御装置、コミュニケーション制御方法及びプログラム
CN111913590A (zh) 一种输入方法、装置和设备

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20190719

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20200325

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20200421

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200617

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20201006

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20201019

R150 Certificate of patent or registration of utility model

Ref document number: 6790613

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350