JP3817518B2 - カード利用サービスへのアクセスのためのシステム - Google Patents
カード利用サービスへのアクセスのためのシステム Download PDFInfo
- Publication number
- JP3817518B2 JP3817518B2 JP2002527988A JP2002527988A JP3817518B2 JP 3817518 B2 JP3817518 B2 JP 3817518B2 JP 2002527988 A JP2002527988 A JP 2002527988A JP 2002527988 A JP2002527988 A JP 2002527988A JP 3817518 B2 JP3817518 B2 JP 3817518B2
- Authority
- JP
- Japan
- Prior art keywords
- card
- application
- data
- service
- message
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/02—Input arrangements using manually operated switches, e.g. using keyboards or dials
- G06F3/023—Arrangements for converting discrete items of information into a coded form, e.g. arrangements for interpreting keyboard generated codes as alphanumeric codes, operand codes or instruction codes
- G06F3/0231—Cordless keyboards
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0487—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser
- G06F3/0488—Interaction techniques based on graphical user interfaces [GUI] using specific features provided by the input device, e.g. functions controlled by the rotation of a mouse with dual sensing arrangements, or of the nature of the input device, e.g. tap gestures based on pressure sensed by a digitiser using a touch-screen or digitiser, e.g. input of commands through traced gestures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K19/00—Record carriers for use with machines and with at least a part designed to carry digital markings
- G06K19/005—Record carriers for use with machines and with at least a part designed to carry digital markings the record carrier comprising an arrangement to facilitate insertion into a holding device, e.g. an arrangement that makes the record carrier fit into an etui or a casing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
- G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
- G06K7/0013—Methods or arrangements for sensing record carriers, e.g. for reading patterns by galvanic contacts, e.g. card connectors for ISO-7816 compliant smart cards or memory cards, e.g. SD card readers
- G06K7/0056—Methods or arrangements for sensing record carriers, e.g. for reading patterns by galvanic contacts, e.g. card connectors for ISO-7816 compliant smart cards or memory cards, e.g. SD card readers housing of the card connector
- G06K7/006—Methods or arrangements for sensing record carriers, e.g. for reading patterns by galvanic contacts, e.g. card connectors for ISO-7816 compliant smart cards or memory cards, e.g. SD card readers housing of the card connector the housing being a portable casing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/346—Cards serving only as information carrier of service
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
- G07F19/20—Automatic teller machines [ATMs]
- G07F19/201—Accessories of ATMs
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/0873—Details of the card reader
- G07F7/088—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself
- G07F7/0886—Details of the card reader the card reader being part of the point of sale [POS] terminal or electronic cash register [ECR] itself the card reader being portable for interacting with a POS or ECR in realizing a payment transaction
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/233—Processing of audio elementary streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/4104—Peripherals receiving signals from specially adapted client devices
- H04N21/4113—PC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/418—External card to be used in combination with the client device, e.g. for conditional access
- H04N21/4182—External card to be used in combination with the client device, e.g. for conditional access for identification purposes, e.g. storing user identification data, preferences, personal settings or data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/422—Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS]
- H04N21/42204—User interfaces specially adapted for controlling a client device through a remote control device; Remote control devices therefor
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/422—Input-only peripherals, i.e. input devices connected to specially adapted client devices, e.g. global positioning system [GPS]
- H04N21/42204—User interfaces specially adapted for controlling a client device through a remote control device; Remote control devices therefor
- H04N21/42206—User interfaces specially adapted for controlling a client device through a remote control device; Remote control devices therefor characterized by hardware details
- H04N21/42224—Touch pad or touch panel provided on the remote control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/426—Internal components of the client ; Characteristics thereof
- H04N21/42684—Client identification by a unique number or address, e.g. serial number, MAC address, socket ID
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/47805—Electronic banking
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/4781—Games
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
- H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
- H04N21/47815—Electronic shopping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- General Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Human Computer Interaction (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Artificial Intelligence (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Marketing (AREA)
- Power Engineering (AREA)
- Input From Keyboards Or The Like (AREA)
- Stored Programmes (AREA)
- User Interface Of Digital Computer (AREA)
- Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)
- Selective Calling Equipment (AREA)
- Credit Cards Or The Like (AREA)
- Telephonic Communication Services (AREA)
- Computer And Data Communications (AREA)
Description
本発明は、リモートリーダ装置と共に使用される制御テンプレート又はスマートカードに関し、特に、サービスを提供するカードインタフェースシステムに関する。また、本発明はカードインタフェースシステムに対するコンピュータプログラムを記録したコンピュータ可読な媒体を含むコンピュータプログラム製品に関する。
【0002】
様々な種類の制御パッドが知られており、かなり多岐に渡る分野で使用されている。通常、このようなパッドは、ユーザが適切な圧力を印加すると信号を発生して関連する制御回路に供給する1つ以上のキー、ボタン、又は感圧領域を含む。
【0003】
しかし、従来の制御パッドは、キー、ボタン、又は感圧領域の単一構成のみを考慮しているという点で多少制限がある。どの分野でも標準のレイアウトが存在することはまれであり、ユーザは使用する各制御パッドに関して新規のレイアウトについて学ぶことを強いられることが多い。例えば、多くの現金自動預払機(「ATM」)及び販売時点電子資金移動(「EFTPOS」)装置は、データ入力での要求事項が比較的類似しているにも関わらず、異なるレイアウトを使用している。このため、ユーザは制御パッドごとに押下する必要のあるボタンの位置を判定しなければならず、混乱を招く可能性がある。このような制御パッドは、ユーザの関心、更には、ユーザの使用能力を超える多くのオプションを提供することが多いので問題は悪化することになる。
【0004】
コンピュータのキーボードなどのためのオーバレイテンプレートが知られている。しかし、これらのテンプレートは設計上柔軟性に乏しく、オーバレイを使用するたびにキーボードが関連付けられているシステムを正確に構成するをユーザに要求している。
【0005】
既知のシステムの1つは、機器のリモート制御のために設計されたスマートカード読取り装置を伴う。この装置により、例えば、テレビメーカはカードを製造し、このカードをリモート制御筐体及びテレビ受像機と共に供給することができる。顧客は、カードと共に筐体をテレビ受像機用のリモート制御装置として使用することができるようになる。テレビメーカ又はラジオメーカは、自社の製品のために固有のリモート制御装置を製造する必要はないが、リモート制御筐体を固有のカードと共に使用することができる。しかし、上述の概念には、カード上に格納され、関連する装置を制御するのに使用される制御データ(PLAYコマンド、RECORDコマンド、REWINDコマンドなど)が装置のメーカによるものであり、そのため、適用が制限されるという欠点がある。
【0006】
別の既知のシステムは、ビデオ装置、オーディオ装置などをリモート制御するのに使用される「リモートコマンダ(remote commander)」として知られる操作カード読取り装置を伴う。この既知のシステムの操作カードは、リモートコマンダがどのモードで操作しているか及びリモートコマンダからどの制御データが送信されるかを識別するためのカード識別メカニズムを含む。操作カード識別メカニズムは、カードの側面に形成される電極/ノッチ及び操作カード内に格納される識別情報のいずれかの形態をとることができる。操作カード識別メカニズムは、リモートコマンダが識別メカニズムの構成によってビデオテープレコーダ及びテレビ受像機のいずれかのためのコマンドを送信できるように構成することができる。この既知のシステムにも、ビデオテープレコーダ又はテレビを制御するのに使用される制御データ(PLAYコマンド、RECORDコマンド、REWINDコマンドなど)が装置のメーカによるものであり、そのため、適用が制限されるという欠点がある。更に、操作カード識別メカニズムは、ユーザが制御対象装置の変更を希望するたびに構成される必要があり、制御対象のビデオ装置、オーディオ装置などとのインタラクションに使用できないように操作カードに限定される。
【0007】
更に別の既知のスマートカードシステムは、テレビのチャンネルから情報を受信するための光学部品及びリモートサービスプロバイダ上で実行されているアプリケーションとのリアルタイム双方向通信を提供するためのモデムを伴う。この既知のスマートカードシステムは、既存のホームショッピングアプリケーションなどのリモートサービストランザクションに使用される。この既知のシステムによると、ホームショッピングプログラム情報、商品名、商品の明細、商品価格、商品CM、及びプログラミングの再実行回数を含む情報をスマートカードへとダウンロードすることができる。スマートカードは、スマートカードのモデムと共にアクセス情報を使用してホームショッピングプログラムの自動サービスコンピュータに自動的にダイヤルし、注文を行なう。しかし、商品購入にスマートカードを使用するたびにアクセス情報をダウンロードしなければならず、商品名及び商品明細により指定される商品を購入する際にしか使用することができないため、このシステムの適用も制限される。
【0008】
上述のシステムは全てが柔軟性に欠けており、それぞれの適用に制限がある。これらのシステムは、全てが事前に実行されるアプリケーションと共に使用され、メーカによる指定のもの以外のアプリケーションとの間にはインタラクションがない。
【0009】
本発明の目的は、既存の構成の1つ以上の欠点をほぼ克服するか、あるいは、少なくとも改善することである。
【0010】
本発明の一面によると、受け入れのためのレセプタクル(receptacle)を有するカード読取り装置へと挿入されるように構成され、印(indicia)が形成された基板を具備するユーザインタフェースカードのユーザにサービスを提供するサービス提供装置であって、
前記カード上に格納されるサービス識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信する中央処理装置を具備し、前記中央処理装置は前記サービス識別子により識別されるサービスを提供するように構成されることを特徴とするサービス提供装置が提供される。
【0011】
本発明の別の面によると、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードのユーザにサービスを提供するサービス提供装置であって、
前記カード内に格納されるサービス識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信する手段と、
前記サービス識別子により識別されるサービスをユーザに提供する手段とを備えるサービス提供装置が提供される。
【0012】
本発明の更に別の面によると、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードのユーザにサービスを提供する方法であって、
前記カード内に格納されるサービス識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信する工程と、
前記サービス識別子により識別されるサービスを提供する工程とを備える方法が提供される。
【0013】
本発明の更に別の面によると、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードのユーザにサービスを提供するサービス提供装置により実行されるプログラムであって、
前記カード内に格納されるサービス識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信するコードと、
前記サービス識別子により識別されるサービスを提供するコードとを備えるプログラムが提供される。
【0014】
本発明の更に別の面によると、機器を制御するために表面に形成される少なくとも1つの印とデータを格納するメモリとを有する制御テンプレートに対する読取り装置と共に使用されるサービス提供装置であって、前記カードが前記読取り装置へと挿入されるように構成されるサービス提供装置であって、
少なくともサービス識別子とユーザにより選択される印と関連付けられる更なるデータとを前記読取り装置から受信する中央処理装置を具備し、前記中央処理装置は前記更なるデータを受信すると前記機器を介して前記サービス識別子と関連付けられるサービスを提供するように構成されるサービス提供装置が提供される。
【0015】
本発明の更に別の面によると、機器を制御するために表面に形成される少なくとも1つの印とデータを格納するメモリとを有する制御テンプレートに対する読取り装置と共に使用されるセットトップボックスであって、前記カードが前記読取り装置へと挿入されるように構成されるセットトップボックスであって、
少なくともサービス識別子とユーザにより選択される印と関連付けられる更なるデータとを具備するデータを前記読取り装置から受信する中央処理装置を具備し、前記中央処理装置は前記更なるデータを受信すると前記機器を介して前記サービス識別子と関連付けられるサービスを提供するように構成されるセットトップボックスが提供される。
【0016】
本発明の更に別の面によると、機器を制御するために表面に形成される少なくとも1つの印とデータを格納するメモリとを有する制御テンプレートに対する読取り装置と共に使用されるコンピュータであって、前記カードが前記読取り装置へと挿入されるように構成されるコンピュータであって、
少なくともサービス識別子とユーザにより選択される印と関連付けられる更なるデータとを前記読取り装置から受信する中央処理装置を具備し、前記中央処理装置は前記更なるデータを受信すると前記機器を介して前記サービス識別子と関連付けられるサービスを提供するように構成されるコンピュータが提供される。
【0017】
本発明の更に別の面によると、基板とその上に形成される印とを具備するインタフェースカードを受け入れるレセプタクルを有するカード読取り装置を使用するカードユーザにサービスを提供するサービス提供装置であって、
前記カードに格納されるサービス識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信する中央処理装置を具備し、前記中央処理装置はユーザにより押下される印に従って前記サービス識別子により識別されるサービスをユーザに提供するサービス提供装置が提供される。
【0018】
本発明の更に別の面によると、基板とその上に形成される印とを具備する取外し可能なインタフェースカードに重なるように構成されるほぼ透明な感圧膜を有するカード読取り装置を使用するカードユーザにサービスを提供する装置であって、
サービス識別子と前記感圧膜上の押下されるユーザ押下座標とを前記読取り装置から受信し、前記座標を前記印と関連付けられるデータと照合して前記サービス提供装置から前記座標と一致するデータを読む中央処理装置であって、ユーザにより押下される印に従って前記サービス識別子により識別されるサービスをユーザに提供する中央処理装置を具備するサービス提供装置が提供される。
【0019】
本発明の更に別の面によると、基板とその上に形成される印とを具備する取外し可能なインタフェースカードに重なるように構成されるほぼ透明な感圧膜を有するカード読取り装置を使用するカードユーザにサービスを提供する装置であって、
前記装置がサービス識別子と前記感圧膜上の押下されるユーザ押下座標とを前記読取り装置から受信する場合に、前記座標を前記印と関連付けられるデータと照合して前記サービス提供装置から前記座標と一致するデータを読み、前記装置が前記印と関連付けられるデータを前記読取り装置から受信する場合にデータを処理する中央処理装置であって、ユーザにより押下される印に従って前記サービス識別子により識別されるサービスをユーザに提供する中央処理装置を具備するサービス提供装置が提供される。
【0020】
本発明の更に別の面によると、基板とその上に形成される印とを具備する取外し可能なインタフェースカードに重なるように構成されるほぼ透明な感圧膜を有するカード読取り装置を使用するカードユーザにサービスを提供する装置であって、
前記感圧膜上のユーザ押下の接触座標を読取り装置から受信し、前記受信された座標に基づいてディスプレイに表示されるカーソルを移動する中央処理装置を具備するサービス提供装置が提供される。
【0021】
本発明の更に別の面によると、インタフェースカードを受け入れるレセプタクルを有するカード読取り装置を使用するカードユーザにサービスを提供するサービス提供装置であって、
前記読取り装置におけるカード挿入の現在のセッションを識別し、カードが前記読取り装置へと挿入されるたびに増分される数値であるセッション識別子を前記読取り装置から受信し、前記受信されたセッション識別子を先に受信されたセッション識別子と比較することによって前記挿入されたカードの有効性を判定する中央処理装置を具備するサービス提供装置が提供される。
【0022】
本発明の更に別の面によると、カスタマイズ可能なユーザインタフェースシステムに対するソフトウェアアーキテクチャであって、
ユーザインタフェース信号を前記システムの全体にわたって解釈可能な形態へと変換するインタフェースモジュールと、
前記インタフェース信号を受信し、前記アーキテクチャのコンポーネント間で前記信号及び更なる信号を送受信するように動作可能なイベントマネージャと、
ユーザインタフェースの活動を識別し、前記ユーザインタフェースに関連する動作と関連付けられると共に前記ユーザインタフェースに関連する1つ以上のアプリケーションの各々の開始及び終了を前記ユーザインタフェースのために管理するランチャモジュールの動作を促すマスタランチャとを具備するアーキテクチャが提供される。
【0023】
本発明の更に別の面によると、ソフトウェアアーキテクチャを使用してカスタマイズ可能なユーザインタフェースシステム内で複数のアプリケーションを起動する方法であって、
ユーザインタフェース信号を前記システムの全体にわたって解釈可能な形態へと変換し、
前記インタフェース信号を受信し、前記アーキテクチャのコンポーネント間で前記信号及び更なる信号を送受信し、
ユーザインタフェースの活動を識別し、前記ユーザインタフェースに関連する動作と関連付けられると共に前記ユーザインタフェースに関連する1つ以上のアプリケーションの各々の開始及び終了を前記ユーザインタフェースのために管理するランチャモジュールの動作を促すことを特徴とする方法が提供される。
【0024】
本発明の更に別の面によると、カスタマイズ可能なユーザインタフェースシステムに対するソフトウェアアーキテクチャであって、
ユーザインタフェース信号を前記システムの全体にわたって解釈可能な形態へと変換するインタフェースモジュールと、
前記インタフェース信号を受信し、前記アーキテクチャのコンポーネント間で前記信号及び更なる信号を送受信するように動作可能なイベントマネージャと、
ユーザインタフェースの活動を識別し、前記ユーザインタフェースに関連する動作と関連付けられると共に前記ユーザインタフェースに関連し各々が前記ユーザインタフェースと関連付けられる対応のサービス識別子を利用してアクセス可能な1つ以上のアプリケーションの各々の開始及び終了を前記ユーザインタフェースのために管理するランチャモジュールの動作を促すマスタランチャとを具備するアーキテクチャが提供される。
【0025】
本発明の更に別の面によると、ソフトウェアアーキテクチャを使用してカスタマイズ可能なユーザインタフェースシステム内で複数のアプリケーションを起動するプログラムであって、
ユーザインタフェース信号を前記システムの全体にわたって解釈可能な形態へと変換するコードと、
前記インタフェース信号を受信し、前記アーキテクチャのコンポーネント間で前記信号及び更なる信号を送受信するコードと、
ユーザインタフェースの活動を識別し、前記ユーザインタフェースに関連する動作と関連付けられると共に前記ユーザインタフェースに関連する1つ以上のアプリケーションの各々の開始及び終了を前記ユーザインタフェースのために管理するランチャモジュールの動作を促すコードとを具備するプログラムが提供される。
【0026】
本発明の更に別の面によると、カードユーザにサービスを提供するサービス提供装置であって、各々がイベントデータに対応するアイコンが表面に形成されたインタフェースカードを受け入れるレセプタクルを有するカード読取り装置と共に使用されるように構成されるサービス提供装置であって、
ユーザにより選択されるアイコンに関連する前記イベントデータを前記カード読取り装置から受信し、前記インタフェースカード内に格納されるサービス識別子に対応するアプリケーションを実行してユーザにサービスを提供する中央処理装置を具備するサービス提供装置が提供される。
【0027】
本発明の更に別の面によると、各々がイベントデータに対応するアイコンが表面に形成されたインタフェースカードを受け入れるレセプタクルを有するカード読取り装置を利用してカードユーザにサービスを提供する方法であって、
ユーザにより選択されるアイコンに関連する前記イベントデータを前記カード読取り装置から受信する工程と、
前記インタフェースカード内に格納されるサービス識別子に対応するアプリケーションを実行して前記ユーザにサービスを提供する工程とから成る方法が提供される。
【0028】
本発明の更に別の面によると、各々がイベントデータに対応するアイコンが表面に形成されたインタフェースカードを受け入れるレセプタクルを有するカード読取り装置を利用してカードユーザにサービスを提供するプログラムであって、
ユーザにより選択されるアイコンに関連する前記イベントデータを前記カード読取り装置から受信するコードと、
前記インタフェースカード内に格納されるサービス識別子に対応するアプリケーションを実行して前記ユーザにサービスを提供するコードとを具備するプログラムが提供される。
【0029】
本発明の更に別の面によると、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードのユーザにサービスを提供するサービス提供装置であって、
前記カード上に格納される識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信し、前記受信された識別子に対応するアプリケーション位置を取得する中央処理装置を具備するサービス提供装置が提供される。
【0030】
本発明の更に別の面によると、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードのユーザにサービスを提供するサービス提供装置により実行されるプログラムであって、
前記カード上に格納される識別子とユーザにより選択される印に関連するデータとを前記読取り装置から受信するコードと、
前記受信された識別子に対応するアプリケーション位置を取得するコードとを具備するプログラムが提供される。
【0031】
本発明のその他の面も開示される。
【0032】
【本発明の実施の形態】
図面を参照しながら本発明の1つ以上の実施形態を説明する。
【0033】
添付のいずれか1つ以上の図面において、同じ符号を有するステップ及び/又は特徴に言及する場合、特に明記されていない限り、以下の記述においては、これらのステップ及び/又は特徴は、同じ機能又は動作を有するものとする。
【0034】
以下に開示される各実施形態は、主に、リモート制御システム、現金自動預払機、ビデオゲームコントローラ、及びネットワークアクセスと共に使用されるべく開発されたものであり、これらの適用例及びその他の適用例を参照して説明する。しかし、本発明がこれらの使用分野に限定されないことは明らかであろう。
【0035】
説明を簡単にする目的で、以下の説明では、第1.0節(section)から第13.0節に分割する。各節は関連する項(subsectioin)を有する。
【0036】
1.0 カードインタフェースシステムの概要
図1は、カードレセプタクル4及び表示領域6を定義する筐体2を有するリモートリーダ1を示す。データ読取り手段が、露出した電気接点7及び関連する制御回路(不図示)の形態で設けられる。また、リモートリーダ1は、表示領域6を覆うタッチパネル8を形成するほぼ透明な感圧膜の形態のセンサ手段を含む。ここで開示されるリモートリーダ1は、タッチパネル8を形成するほぼ透明な感圧膜を用いて説明されるが、代替の技術をほぼ透明なタッチパネルとして使用できることが当業者には明らかであろう。例えば、タッチパネルは電気抵抗の高いものにすることも、感温性のものにすることもできる。リモートリーダ1は、ユーザインタフェースカードと共に使用するように構成される。図1から図3に示すカードにおいて、ユーザインタフェースカードは電子スマートカード10Aの形態をとる。スマートカード10Aは、4方向コントローラ20、上面16に印刷された「ジャンプボタン」22、「キックボタン」24、「開始ボタン」、及び「終了ボタン」の形態の種々の制御印14を有する積層基板12を含む。プロモーション素材又は教示的な素材などの他の非制御印を制御印の横に印刷することができる。例えば、図2に示すように、広告素材26をスマートカード10Aの前面又は裏面27に印刷することができる。
【0037】
図3に示すように、スマートカード10Aは制御印と関連付けられるデータに対してオンボードメモリチップ19の形態の記憶手段を含む。また、スマートカード10Aは、オンボードメモリチップ19に接続されると共にリモートリーダ1上の露出した接点7に対応する電気データ接点18を含む。
【0038】
図3に示すように、上面16は、制御印14が印刷された粘着ラベル60により形成されても良い。ここで、制御印14は「終了ボタン」及び方向コントローラ20の右矢印「ボタン」に対応する。ラベル60は積層基板12に貼付される。一般家庭のユーザは、Canon, Inc製のカラーBUBBLEJET(登録商標)プリンタなどのプリンタを使用することによって、特定のスマートカード10Aと共に使用するための適切なラベルを印刷することができる。また、制御印14を積層基板に直接印刷することも、各制御印に別々の粘着ラベルを使用することもできる。
【0039】
使用の際、スマートカード10Aはカードレセプタクル4へと挿入されるので、感圧タッチパネル8はスマートカード10Aの上面16を覆うようになる。このとき、制御印は透明な感圧タッチパネル8を通して表示領域6内に見えることになる。
【0040】
リーダ1の露出した接点7及び関連回路は、スマートカード10Aの制御テンプレートレセプタクル4への挿入時に自動的に、あるいは、リモートリーダ1からの信号に応答して選択的に、メモリチップ19から制御印14と関連付けられた格納データを読むように構成される。信号は、例えば、露出した接点7及びデータ接点18を介してスマートカード10Aに送信することができる。
【0041】
制御印14と関連付けられたデータが一度読み取られると、ユーザは感圧タッチパネル8の制御印14に重なる各領域を押下することができる。感圧タッチパネル8にかかる圧力を検知し、格納データを参照することによって、リモートリーダ1はユーザが選択したのがどの制御印14であるかを推定することができる。例えば、ユーザが感圧タッチパネル8の「キックボタン」24の付近に圧力をかける場合、リモートリーダ1は圧力が印加された位置を推定し、格納データを参照し、「キック」ボタン24が選択されたと判定するように構成される。この情報を使用して、関連するビデオゲームコンソール(従来の構成のもの、不図示)などの外部装置を制御することができる。以上の説明から、制御印14は実際にはボタンでないことが認識されるであろう。制御印14は、タッチパネル8のマッピングデータ及び機能との対応する結び付きによって、リモート制御装置と従来から関連付けられてきたボタンをエミュレートするように動作するユーザ選択可能な機能である。
【0042】
1つの有利な実現例において、リモートリーダ1は、ユーザにより選択される印に関連する情報を送信するための赤外線(IR)送信機又は無線周波数(RF)送信機などの送信機(従来の構成のもの、不図示)を含む。図1に示すように、リモートリーダ1はIR発光ダイオード(LED)25を有するIR送信機を組み込む。制御印14のうちの1つを選択すると、リモートリーダ1は選択された印に関連する情報をリモートコンソール(図1では示されていない)に送信させる。リモートコンソールでは、対応するIR受信機又はRF受信機により、リーダ1のユーザがプレーするゲームなどの何らかの機能を制御する際に使用される情報を検知・復号化することができる。
【0043】
直接ハード配線を含む任意の適切な送信方法を使用してリモートリーダ1からリモートコンソールへと情報を送信することができる。更に、先に説明したのと逆の方向に送信するために、リモートコンソール自体が送信機を組み込み、リモートリーダ1が受信機を組み込むこともできる。リモートコンソールからリモートリーダ1への送信は、例えば、ハンドシェーキングデータ、セットアップ情報、又はリモートコンソールからリモートリーダ1に送信することが望まれる任意の形態の情報を含むことができる。
【0044】
図4に戻ると、制御カード10Bが示される。制御カード10Bは、制御印(不図示)を有する積層基板12を含む。制御カード10Bにおいて、記憶手段は制御カード10Bの裏面27の縁部28に沿って形成される磁気ストリップ29の形態をとる。制御印と関連付けられる格納データは、従来のように磁気ストリップ29に格納されても良い。この構成の対応するリーダ(不図示)は、対応する制御テンプレートレセプタクルへの入口部又はその付近に位置する磁気読取りヘッドを含む。制御カード10Bがカードレセプタクルへと差し込まれるとき、格納データは磁気読取りヘッドにより磁気ストリップ29から自動的に読み取られる。リーダ1は図1のカード10Aに対応する方法で操作されても良い。
【0045】
図5は制御カード10Cの形態の別のカードを示す。制御カード10Cにおいて、記憶手段は機械読取り可能な印の形態をとる。図5のカード10Cにおいて、機械読取り可能な印は、カード10Cの裏面27の縁部38に沿って形成されるバーコード36の形態をとる。格納データは符号化されているのが好ましく、図示する位置に印刷される。図5のカード10Cの対応するコントローラ(不図示)は、関連する制御テンプレートレセプタクルへの入口部又はその付近に位置する光学読取りヘッドを含むことになる。カード10Cがカードレセプタクルへと差し込まれるとき、格納データは光学読取りヘッドによりバーコード36から自動的に読み取られる。また、バーコードは、カード10Cを挿入する直前にリーダと関連するバーコードリーダを使用して走査することも、カード10Cが完全に挿入されてから内部のバーコードリーダスキャナにより走査することもできる。カード10Cは、その後図1のカード10Aに対応する方法で操作されても良い。バーコードの位置、向き、及び符号化は、特定のアプリケーションに適合するように変更可能であることが認識されるであろう。更に、エンボス加工の機械読取り可能な図形、印刷された英数字、パンチングやその他の方法で形成された切抜き、光学的な印又は光磁気の印、2次元バーコードを含むその他の任意の形態の機械読取り可能な印を使用することができる。
【0046】
図6(a)は、カードインタフェースシステム600Aのハードウェアアーキテクチャを示す。システム600Aにおいて、リモートリーダ1は通信ケーブル3を介してパーソナルコンピュータシステム100に配線接続される。あるいは、配線接続の代わりに無線周波数送受信機又はIR送受信機106を使用して、リモートリーダ1と通信を行なうことができる。パーソナルコンピュータシステム100は画面101及びコンピュータモジュール102を含む。パーソナルコンピュータシステム100については、図7を参照して以下で更に詳細に説明する。キーボード104及びマウス203も設けられる。
【0047】
システム600Aは、上述のスマートカード10Aと同様の構成のスマートカード10Dを含む。スマートカード10Dはプログラム可能であり、サードパーティにより作製又はカスタマイズすることができる。この場合、サードパーティは、カード10D及び/又はカードリーダ1のメーカ以外の業者であっても良い。サードパーティは、スマートカード10D自体の最終ユーザであっても、メーカとユーザとの間の仲介業者であっても良い。図6(a)のシステム600Aによると、スマートカード10Dは1回の接触操作でコンピュータ100と通信を行ない、インターネットなどのネットワーク220を介してサービスを取得するようにプログラム・カスタマイズすることができる。コンピュータ100は、特定のプロトコルに従ってリモートリーダ1から通信ケーブル3を介して送信される信号を解釈するように動作する。このプロトコルについては詳細に後述する。コンピュータ100は、触れられた制御印に従って選択された機能を実行し、ネットワーク220を介してデータを送受信するように構成することができる。このように、コンピュータ100は、リモートサーバコンピュータ150、152上に格納されたアプリケーション及び/又はデータへのアクセスを許可し、表示装置101での適切な再現を可能にすることができる。
【0048】
図6(b)は、カードインタフェースシステム600Bのハードウェアアーキテクチャを示す。システム600Bにおいて、出力インタフェースに接続するセットトップボックス601においてローカルにサービスを取得するためにリモートリーダ1をプログラムすることができる。出力インタフェースは、ここではデジタルテレビ受信機などの音声映像出力装置116の形態をとる。セットトップボックス601は、リモートリーダ1から特定のプロトコル(詳細に後述)に従って受信される信号112を解釈するように動作する。この信号112は、電気信号であっても、無線周波数信号であっても、あるいは赤外線(IR)信号であっても良い。セットトップボックス601は、触れられた制御印に従って選択された機能を実行し、出力装置116での適切な再現を可能にするように構成することができる。また、セットトップボックス601は、信号112を通信に適した形態に変換し、コンピュータ100への適切な送信を行なうように構成することができる。このため、コンピュータ100は、制御印に従って選択された機能を実行し、セットトップボックス601にデータを提供することで出力装置116での適切な再現を可能にすることができる。セットトップボックス601については、図42を参照して以下で詳細に説明する。
【0049】
システム600Bの1つの適用例において、スマートカード10Dはサービスをリモートで又はローカルに取得するためにプログラムすることができる。例えば、スマートカード10Dは、リモートサーバコンピュータ150、152上に格納されたアプリケーション及び/又はデータをネットワーク220を介して取得し、これをセットトップボックス601へとロードするようにプログラムすることができる。後者の場合、カードはセットトップボックス601上のロードされたアプリケーションからサービスを取得するようにプログラムすることもできる。
【0050】
特に明記する場合を除き、以降、システム600A及び600Bをシステム600と総称的に呼ぶ。更に、特に明記する場合を除き、以降、スマートカード10A、10B、10C、及び10Dを総称的にスマートカード10と呼ぶ。
【0051】
図7は、システム600の汎用コンピュータシステム100を示す。このシステムを使用してカードインタフェースシステムを実行させると共に、スマートカード10をプログラムするためのソフトウェアアプリケーションを実行させることができる。コンピュータシステム100は、コンピュータモジュール102、キーボード104及びマウス203などの入力装置、並びにプリンタ(不図示)及び表示装置101を含む出力装置を具備する。変復調(モデム)送受信装置216は、コンピュータモジュール102が、例えば、電話回線221又はその他の機能媒体を介して接続可能な通信ネットワーク220と通信を行なうのに使用される。モデム216は、インターネット及び構内通信網(LAN)又は広域通信網(WAN)などのその他のネットワークシステムへのアクセス権を取得するのに使用することができる。
【0052】
コンピュータモジュール102は、通常、少なくとも1つの中央処理装置(CPU)205、例えば、半導体ランダムアクセスメモリ(RAM)及び読出し専用メモリ(ROM)から形成されるメモリユニット206、ビデオインタフェース207とキーボード104及びマウス203用のI/Oインタフェース213とを含む入出力(I/O)インタフェース、書込み装置215、並びにモデム216用のインタフェース208を含む。記憶装置209が設けられるが、この記憶装置209は、通常、ハードディスクドライブ210及びフロッピーディスクドライブ211を含む。磁気テープドライブ(不図示)を使用しても良い。CD−ROMドライブ212は、通常、不揮発性のデータソースとして設けられる。コンピュータモジュール201の構成要素205から213は、通常、相互接続バス204を介して、コンピュータシステム102の動作モードが、当業者には既知の従来の動作モードになるように通信を行なう。上述の構成を実施可能なコンピュータの例としては、IBMのコンピュータ及びその互換機、Sun Sparcstation、又はそれを進化させた同様のコンピュータシステムがある。
【0053】
通常、システム600のソフトウェアプログラムはハードディスクドライブ210に常駐し、CPU205による実行の際に読み出されて制御される。ソフトウェアアプリケーションプログラムとネットワーク220から取り込まれるデータとの中間記憶装置は、半導体メモリ206を使用し、場合によってはハードディスクドライブ210と協働させるように使用して達成されても良い。アプリケーションプログラムは、CD−ROM又はフロッピーディスク上に符号化された形でユーザに供給され、対応するドライブ212又は211を介して読み取られる場合もあれば、ネットワーク220からモデム装置216を介してユーザが読み取る場合もある。更に、ソフトウェアは、磁気テープ、ROM又は集積回路、光磁気ディスク、コンピュータモジュール102と別の装置との間の無線又は赤外線の伝送チャネル、スマートカード及びコンピュータのPCMCIAカードなどのコンピュータ可読なカード、並びに電子メール送受信及びウェブサイトなどに記録された情報などを含むインターネット又はイントラネットを含む他のコンピュータ可読な媒体からコンピュータシステム102へとロードすることもできる。以上の例は、関連するコンピュータ可読な媒体の一例に過ぎない。添付の請求の範囲により定義される本発明の趣旨から逸脱することなく、その他のコンピュータ可読な媒体も実施することができる。
【0054】
スマートカード10は、コンピュータモジュール102のI/Oインタフェース213に接続される書込み装置215を用いてプログラムすることができる。書込み装置215は、スマートカード10上のメモリにデータを書き込む機能をもつことができる。また、書込み装置215は、スマートカード10の上面に図形を印刷する機能を有するのが好ましい。書込み装置215は、スマートカード10上のメモリからデータを読み取る機能ももつことができる。まず、ユーザはスマートカード10を書込み装置215へと挿入する。ユーザが汎用コンピュータ102のキーボード104を介して所要のデータを入力すると、ソフトウェアアプリケーションが書込み装置215を介してこのデータをスマートカードのメモリに書き込む。格納データがバーコードの使用などの光学的な復号化用に符号化されている場合、書込み装置は符号化されたデータをスマートカード10に印刷することができる。
【0055】
図42は、システム600のセットトップボックス601を示す。このセットトップボックス601を使用してリモートリーダ1から受信された信号112を解釈することができる。一部の実現例では、セットトップボックス601は実質的にコンピュータモジュール102の規模を変更したものとなる。セットトップボックス601は、通常、少なくとも1つのCPUユニット4305、例えば、半導体ランダムアクセスメモリ(RAM)及び読出し専用メモリ(ROM)から形成されるメモリユニット4306、並びにデジタルテレビ116用のI/Oインタフェース4313、信号112を送受信するためのIR送受信機を有するI/Oインタフェース4308、ネットワーク220に接続するためのI/Oインタフェース4317とを少なくとも含む入出力(I/O)インタフェースを含む。セットトップボックス601の構成要素4305、4306、4313、4315、及び4317は、通常、相互接続バス4304を介して、動作モードが従来の動作モードになるように通信を行なう。リモートリーダ1又はネットワーク220から受信されるデータの中間記憶装置は、半導体メモリ4306を使用して達成されても良い。また、セットトップボックスは記憶装置209と同様の記憶装置(不図示)を含むことができる。
【0056】
カードインタフェースシステム600については、以下の段落で詳細に説明する。
【0057】
2.0 カードインタフェースシステムソフトウェアアーキテクチャ
2.1 ソフトウェアアーキテクチャのレイアウト
システム600により表されるハードウェアアーキテクチャに対するソフトウェアアーキテクチャ200がほぼ図8に示される。アーキテクチャ200は、幾つかの別個のプロセスコンポーネント及び1つのプロセスクラスへと分割することができる。別個のプロセスには、口語で「I/Oデーモン」300とも呼ばれるI/Oインタフェース300、イベントマネージャ301、ディスプレイマネージャ306、(アプリケーション)ランチャ303、及びディレクトリサービス311が含まれる。プロセスクラスは1つ以上のアプリケーション304により形成される。ここで説明するアーキテクチャ200には、セットトップボックス601により通常形成されるスマートカードリモート接続ごとに、1つのI/Oデーモン300、1つのイベントマネージャ301、1つのディスプレイマネージャ306、及び1つのランチャ303と、各ランチャ303を稼動させているコンピュータ100(例えば、サーバコンピュータ150、152)ごとに1つのマスタランチャ(不図示)と、全てのシステムに対して少なくとも1つのディレクトリサービス311とが存在する。ランチャ303は、サービスの名前又は位置あるいはそのサービスに対して使用されるアプリケーション304の名前又は位置を示すリソースロケータ(URLなど)へとサービスデータを変換するためにディレクトリサービス311に問合せを行なう。
【0058】
アーキテクチャ200は、図8の破線により示されるように、6つの別個の部分101、307、309、312、313、及び601へと物理的に分離することができる。各部分は物理的に別々の計算装置上で実行させることができる。システム600の各部分間の通信は、伝送制御プロトコル/インターネットプロトコル(TCP/IP)ストリームを使用して実行される。また、各部分101、307、309、312、313、及び601は、同じマシン上で実行させることもできる。
【0059】
図6(a)のシステム600Aにおいて、プロセスコンポーネント300、301、303、304、及び306の全てはコンピュータ100上で実行させることができる。イベントマネージャ301、ランチャ303、及びディスプレイマネージャ306は、コンピュータ100のハードディスク209に格納され、CPU205による実行時に読み出して制御することができる1つの実行可能なプログラムへと統合されるのが好ましい。ディレクトリサービス311は、同じコンピュータ100又はネットワーク220を介してコンピュータ100に接続される別のコンピュータ(サーバ150など)上で実行される。
【0060】
図6(b)のシステム600Bにおいて、コンポーネント300から304及び306の全てはセットトップボックス601から実行させることができる。この例において、コンポーネント300から304及び306はセットトップボックス601のメモリ4306に格納することができ、CPU4305による実行時に読み出して制御することができる。ディレクトリサービス311は、コンピュータ100上で実行させることができると共にコンピュータ100のメモリ206に格納することができる。ディレクトリサービス311はCPU205による実行時に読み出して制御することができる。また、ディレクトリサービス311をセットトップボックス601上で実行させたり、あるいは、その機能をランチャ303により実行させたりすることもできる。
【0061】
セットトップボックス601がシステム600をローカルに実行させるのに十分な能力をもたない場合、I/Oデーモン300のみをセットトップボックス601上で実行させれば良く、アーキテクチャ200のその他の部分(すなわち、プロセスコンポーネント301、303、304、306、及び311)は他のサービス(150、152)上においてリモートで実行させることができる。他のサービスには、ネットワーク220を介してアクセスすることができる。この例では、I/Oデーモン300はセットトップボックス601のメモリ4306に格納することができ、CPU4305による実行の際に読み出して制御することができる。このようなシステムの機能部分も図8に示すように分割することができる。
【0062】
2.1.1 I/Oデーモン
I/Oデーモン300は、リモートリーダ1から受信されたデータグラムをTCP/IPストリームへと変換するプロセスコンポーネントである。このTCP/IPストリームは、イベントマネージャ301へと送信することができると同時にイベントマネージャ301から受信することもできる(例えば、双方向プロトコルを使用するとき)。リモートリーダ1は任意の適切なデータ形式を使用することができる。I/Oデーモン300はリモートリーダ1のデータ形式の変更に影響されないのが好ましく、リモートリーダ1の複数の構成に対処することができる。システム600の1つの有利な実現例では、I/Oデーモン300はイベントマネージャ301へと統合される。
【0063】
システム600Aにおいて、ユーザがコンピュータ100を起動することによってスマートカードシステム600を開始し、イベントマネージャ301が開始されているとき、I/Oデーモン300が開始される。また、ユーザがセットトップボックス601の電源を入れることによってシステム600を開始するとき、I/Oデーモン300が開始される。
【0064】
I/Oデーモン300については第9.0節を参照して以下で更に詳細に説明する。
【0065】
2.1.2 イベントマネージャ
イベントマネージャ301は、全ての通信がイベントマネージャ301を経由するという点でアーキテクチャ200の中心を形成する。イベントマネージャ301は、リモートリーダ1により生成され、I/Oデーモン300により中継される全てのイベントを収集するように構成される。これらのイベントは、種々のプロセスコンポーネント300から304及び306並びに実行中の各アプリケーションへと再分配される。また、イベントマネージャ301は、イベントが有効なヘッダ、正しいデータ長を有することをチェックするように構成されるが、通常、イベントが正しい形式であることをチェックするようには構成されていない。ここでの「イベント」は、I/Oデーモン300、ランチャ303、又はアプリケーション304からの単一のデータトランザクションを表す。
【0066】
異なるシステム間でのプロトコルの変更にはイベントマネージャ301が対処する。可能な場合には、現在実行中のアプリケーション304により理解されるデータ形式に適合するようにイベントを書き換えることができる。書き換えが可能でない場合、イベントマネージャ301は送信元のアプリケーション304にエラーを報告する。例えば、複数枚のスマートカードを稼働させるシステムにおいて、異なるデータ形式が使用されている場合、イベントマネージャ301は混乱の発生を最小限に抑えることを保証するのが好ましい。
【0067】
イベントマネージャ301は、表示画面又はその他の出力装置116にはその存在を示さない。しかし、イベントマネージャ301は、どのアプリケーションが現在必要とされており(すなわち、「フロント」アプリケーション)、現在画面101に表示されるべきであるかについてディスプレイマネージャ306に指示するように構成することができる。イベントマネージャ301は、ランチャ303からアプリケーション304へと渡されるメッセージからこの情報を推定する。これについては、第10.0節を参照して以下で詳細に説明する。
【0068】
イベントマネージャ301は、I/Oデーモン接続の受信の有無を常に聞き取るように構成することも、あるいは、システム600を開始させることもできる。使用される方法はシステム600の全体的な構成によって決まる。イベントマネージャ301がシステム600を開始させることができるか、あるいは、セットトップボックス601がI/Oデーモン300の接続の受信を使用してシステム600を開始させることができる。イベントマネージャ301については、第7.0節を参照して以下で更に詳細に説明する。
【0069】
2.1.3 マスタランチャ
シン(thin)クライアントコンピュータが利用され、各々が1つのセットトップボックスを担当する複数のランチャ303が実行されている場合、イベントマネージャ301と直接通信を行なうマスタランチャ(不図示)を使用することができる。マスタランチャは、2つ以上のイベントマネージャ301がシステム600上で実行されている場合に、各イベントマネージャ301に対応するランチャ303を開始するのに使用される。まず、I/Oデーモン300がイベントマネージャ301に接続するとき、マスタランチャがイベントマネージャ301に対して第1のプロセスを開始するよう、イベントマネージャ301が要求する。この第1のプロセスは、通常、任意のスマートカードアプリケーション304に対するランチャ303である。また、マスタランチャは、イベントマネージャ301が要求するときにはアプリケーション304のランチャ303を停止し、イベントマネージャ301にランチャ303が終了したことを通知するように構成することができる。
【0070】
関連するスマートカードアプリケーション304を実行中の物理的に別々のサーバ(例えば、150、152)ごとに1つのマスタランチャが実行されるのが好ましい。この1つのマスタランチャは特定のサーバ上でランチャを要求する全てのイベントマネージャに対する要求を扱う。図7に示すようにコンピュータ100上で実行されるときには、マスタランチャはシステム600のその他の部分より前又はそれと同時に動作を開始する。この例では、マスタランチャは最初に開始される。
【0071】
マスタランチャは、例えば、関連するランチャがイベントマネージャ301と同じコンピュータ上で実行されているときには、イベントマネージャ301へと統合することができる。
【0072】
2.1.4 ランチャ/第1のアプリケーション
システム600の1つの有利な実現例では、スマートカード10のリモートリーダ1への挿入により開始される第1のプロセスはランチャ303である。特定のシステムでは特定のアプリケーションが開始されるであろう。例えば、自動現金預払機はバンキングアプリケーションを開始することができる。別の例としては、特定の1組のアプリケーションのみを開始する限定されたランチャの使用が含まれる。ランチャ303は、特定のイベントマネージャ301に対して他のアプリケーションを開始するアプリケーションである。ランチャ303はアプリケーションを開始/終了させることができると共に、各セッションを開始/終了させることができる。また、ランチャ303はイベントマネージャ301にいつアプリケーションが開始/終了するかを通知し、アプリケーション304にいつフォーカスを受け取る/失うか、あるいは、いつ終了する必要があるかを通知する。これに関して、複数のアプリケーション304が同時に動作している場合、現在画面に表示されているアプリケーション304がフォーカスを有し、「フロントアプリケーション」として知られるアプリケーションである。別のアプリケーションが優先権を得ようとすると、ランチャ303はフロントアプリケーションにフォーカスが失われることを通知するので、現在のアプリケーションは当座のタスクを完了することができる。また、ランチャ303は新規のアプリケーション304にフォーカスが得られ、まもなくアプリケーション304が変更状態に入ることを通知する。ランチャ303はアプリケーションを強制的に終了するようにも構成される。
【0073】
ランチャ303は、リモートリーダ1が生成する「カードなし」、「バッテリの電力低下」、及び「不良カード」などのイベントを受信しても良い。また、ランチャ303は、現在フロントアプリケーションでない各アプリケーション用のイベントも受信し、これらのイベントを正確に解釈するように動作する。
【0074】
ランチャ303は、イベントマネージャ301によりその開始を要求する要求が生成されるときにのみ開始されるのが好ましい。また、ランチャ303は、イベントマネージャ301により終了するように指示したり、強制的に終了したりすることもできる。
【0075】
ランチャ303はディレクトリサービス311と通信を行なう必要がある唯一のプロセスコンポーネントであるのが好ましい。新規のアプリケーション304を開始する必要があるとき、ランチャ303はサービスデータを有するディレクトリサービス311に問合せを行なう。ディレクトリサービス311は、アプリケーション304の位置及び新規のアプリケーション304と関連付けられるサービスデータを戻す。サービスデータは、ここでは、EM_GAINING_FOCUSイベントと呼ばれるイベント中の初期化データとして新規のアプリケーション304に送信される。アプリケーション位置は実行対象のアプリケーション304の位置を指定する。これは、ローカルコンピュータを用いた実現例ではローカルなものであっても良く、あるいは、ネットワーク化されていても良い。アプリケーション位置が空である場合、ランチャ303はサービスデータに基づいてどのアプリケーションを開始すべきかを決定しなければならない。
【0076】
ランチャ303は、システム600の動作中はほぼ常に実行されているであろうブラウザコントローラなどの任意のアプリケーションを開始するように構成することもできる。このようなアプリケーションは永続的アプリケーションと呼ばれる。アプリケーションは、対応するスマートカード10上での最初のユーザ選択に応答して、あるいは、アプリケーション304のうちの別の1つの要求に応じてランチャ303により開始することができる。
【0077】
システム600の一部の実現例では、ランチャ303はイベントマネージャ301へと統合することができる。
【0078】
ランチャ303については、第10.0節を参照して以下で更に詳細に説明する。
【0079】
2.1.5 ディスプレイマネージャ
ディスプレイマネージャ306は、どのスマートカードアプリケーション304が現在表示画面101上に出力を表示することができるかを選択する。ディスプレイマネージャ306には、ランチャ303が送信元であるEM_GAINING_FOCUSイベントにより表示できるのがどのアプリケーション304であるのかが通知される。このイベントはディスプレイマネージャ306に直接送信することもできるが、イベントマネージャ301がディスプレイマネージャ306及び予定される受信者にイベントのコピーを送信することもできる。
【0080】
一般的に、出力を表示するように試みるべき唯一のアプリケーション304はフロントアプリケーションである。ディスプレイマネージャ306は、表示の制御権を有する各アプリケーション間での切り替え中に安定した出力を提供することができる。ディスプレイマネージャ306は、フロントアプリケーションとしての各アプリケーションの切り替え中には推定のデータを使用する必要があるかもしれない。
【0081】
アーキテクチャ200は、ディスプレイマネージャ306が必要とされない、あるいは、ディスプレイマネージャ306の役割がアーキテクチャ200の別の部分301又は303により想定されても良いように構成することができる。
【0082】
2.1.6 ディレクトリサービス
ディレクトリサービス311は、スマートカード10上に格納されるサービス識別子をサービスの位置又はサービスと関連付けられるアプリケーションの位置を示すリソースロケータ(URLなど)へと変換するように構成される。また、ディレクトリサービス311はオプションのサービスデータを変換するようにも構成される。ディレクトリサービス311は、特定のカード10と関連付けられたランチャ303がリソースロケータを用いて何をすべきか、例えば、関連するアプリケーション304をダウンロード・実行するか、あるいは、リソースロケータをブラウザアプリケーションへとロードするかを決定できるようにする。
【0083】
2.1.7 アプリケーション
特定のスマートカード10と関連付けられたアプリケーション304は、対応するカード上の最初のボタン押下に応じて、スマートカード10と関連付けられたランチャ303により開始することができる。各アプリケーション304は1つ以上のサービスグループのメンバであることもできる。このサービスグループについては本明細書で後述する。アプリケーション304は、任意のサービスグループの一部とならないように指定することができ、この場合、アプリケーションは他のアプリケーションと共に実行されることはない。アプリケーションは、実行中になればサービスグループの一部となることができ、そのアプリケーションが現在フロントアプリケーションであるときにはサービスグループから外れることができる。
【0084】
一部のアプリケーションは、システム600が始動されると開始することができ、これらのアプリケーション、例えば、ブラウザ制御アプリケーション又はメディアプレーイングアプリケーションは常に実行させることができる。これらの永続的アプリケーションはシステム固有であっても、より汎用的に適用可能なものであっても良い。
【0085】
図9は、上述のプロセスコンポーネント301から306を含むカードインタフェースシステムの概略ブロック図表現である。図9のシステムにおいて、リモートリーダ1はIRリンク及びそれを制御するためのI/Oデーモン300を介してコンピュータ100と通信を行なう。更に、コンピュータ100は、ここではウェブサーバ410に対するインターネット400により表される通信ネットワークと通信を行なうように構成される。この例において、スマートカード10及びリモートリーダ1を利用してアクセス可能なアプリケーション304の一部は、様々なスマートカード10と関連付けられるウェブページ406であることもできる。ウェブライブラリ407は、スマートカード10と共に使用されるウェブページに含まれる可能性がある関数(例えば、Javascript関数)及びクラス(Javaクラス)を含む。ウェブページ406は、ウェブブラウザ403と呼ばれる実行中のアプリケーションを用いてアクセスすることができる。図9のシステムにおいて、イベントマネージャ301はリモートリーダ1からイベントを受信するように構成される。イベントはランチャ303に送信される。ランチャ303はウェブブラウザ403を制御するブラウザコントローラ402にメッセージを送信するように構成することができる。アプリケーションセッション又はブラウザセッションを開始するプロセスについては以下で詳細に説明する。ランチャ303は、ファイルサーバ411から実行中のアプリケーションと共にアプリケーション408もダウンロードするように構成することができる。ファイルサーバ411はインターネット400を介してコンピュータ100に接続される。
【0086】
3.0 リーダ
リモートリーダ1は、スマートカード10とインタフェースをとってカスタマイズ可能なユーザインタフェースを提供するハンドヘルド・バッテリ駆動のユニットであるのが好ましい。上述のように、リモートリーダ1は、デジタルTV、セットトップボックス、コンピュータ、又はケーブルTV機器と共に使用されることを意図しており、家庭環境におけるオンライン顧客サービスに対する簡単で直感的なインタフェースを提供する。
【0087】
図43及び44は上述のリーダ1と同様のリーダ4401を示す。リーダ4401はカード10の読取りのために構成される。リーダ4401はカードレセプタクル4404及び表示領域4406を組み込む筐体4402により形成される。カードレセプタクル4404は、図1に示されるスマートカード10を挿入可能なアクセス開口部4410を含む。
【0088】
表示領域4406の上側境界は、上述の膜8と同様のほぼ透明な感圧膜4408の形態のセンサ手段により定義される。膜4408の下方に配置されるのは、スマートカード10の相補的な接点に接触するように構成される露出した電気接点4407の構成の形態で設けられるデータ読取り手段である。
【0089】
図45に示すように、カード10はアクセス開口部4410を介してリーダ4401へと挿入される。リーダ4401の構成により、ユーザはリーダ4401を一方の手に保持し、他方の手でスマートカード10をリーダ4401へと簡単に挿入することができる。スマートカード10がリーダ4401に完全に挿入されると、感圧膜4408はスマートカード10の上面16を完全に覆うようになる。表示領域4406は、上面16が透明な感圧膜4408を通して表示領域4406内に事実上完全に見えるようにカード10の上面16とほぼ同じ寸法を有するのが好ましい。
【0090】
図46は、カードが完全に挿入された後にリーダ4401を操作するユーザを示す。
【0091】
図47(a)から図47(c)において、筐体4402は、膜4408を包囲する最上部4827と、最上部4827との接続部4829から膜4408の横方向の中心の下方にあり且つこれに近接する位置4811まで延出するベース部4805とにより定義される実質的に二部構成の外部ケーシングから形成される。ベース部4805は、赤外線(IR)透過材から形成される対向端面4815を含むので、IR通信情報をリーダ4401により送ることができる。
【0092】
位置4811は、ベース部4805とカード支持面4807との接続点を定義する。カード支持面4807は、接点4407が面4807と最上部4827との間で膜4408を挟持する内部接合部4835の方に位置する平面を通って延出する。アクセス開口部4410は、図47(a)に示すように、位置4811と筐体4402の周縁部4836との間の空間により実質的に定義される。
【0093】
接点4407は、プリント回路基板(PCB)4801上に設置されるコネクタブロック4837から延出する。PCB4801は、2つのマウンティング4817及び4819によりベース部4805と支持面4807との間に配置される。PCB4801のコネクタブロック4837に対向する側には、コネクタ4407及びタッチセンシティブ膜4408に電気的に接続され、膜4408の押下に応じてカード10からデータを読み取るように構成された電子回路(不図示)が配置される。PCB4801からは、制御対象の装置(セットトップボックス601など)との通信用のIRウィンドウとして機能する端部4815に隣接して配置される赤外線発光ダイオード(LED)4800も取り付けられている。
【0094】
図47(b)は、スマートカード10がアクセス開口部4410を介してレセプタクル4404に部分的に挿入された図47(a)に類似する図を示す。図47(b)において明らかなように、支持面4807は、接点4407の平面から接合部4811に向かって下方に延出する一体的に形成された曲線状の輪郭4840を有する。この構成により、図47(b)に示すように、スマートカード10が最初はレセプタクル4404の平面に対して傾斜するように、リーダ4401はスマートカード10を受け入れる。支持面4807の曲線状の輪郭部4840の構成により、ユーザの手の力を受けるとスマートカード10は完全な挿入位置にまで導かれる。具体的には、カード10が更に挿入されると、支持面4807の湾曲がカード10を接点4407及びレセプタクル4404の平面へと導く。
【0095】
図47(c)は、スマートカード10がレセプタクル4404に完全に挿入された図47(a)に類似する図を示す。このとき、カード10は、レセプタクル4404及びスマートカード10のデータ接点(不図示)のうちの関連する1つに接触する接点4407の平面に位置する。スマートカード10は感圧膜4408により覆われる。更に、接点4407はカード10に対向する力を提供するように動作するばね接点であって、膜4408と関連付けられるのが好ましい。この構成は、適切な衝突収納(neat interfernce fit)によりカード10をレセプタクル内に保持するのに十分である。
【0096】
以下の説明では、リーダ1への言及は、図1のリーダ1又は図43から図47(c)のリーダ4401として実現されるリーダへの言及として解釈される。
【0097】
図10は、リモートリーダ1の内部構成を更に詳細に示す概略ブロック図である。リモートリーダ1は、リモートリーダ1を制御し、リモートリーダ1と、例えば、セットトップボックス601との間の通信を調整し、マッピング情報を格納するためのマイクロコントローラ44を含む。マイクロコントローラ44は、ランダムアクセスメモリ(RAM)47及びフラッシュ(ROM)メモリ46を含む。また、マイクロコントローラ44は中央処理装置(CPU)45を含む。マイクロコントローラ44はクロックソース48とマイクロコントローラ44内のイベントのタイミングを調整するためのクロックコントローラ43とに接続される。CPU45には5Vバッテリ53からの電力が供給され、CPU45の動作は電源制御装置50により制御される。マイクロコントローラ44は、カードエントリ状態について及び「ボタン」押下に対して可聴のフィードバックを与えるためのビーパ51にも接続される。
【0098】
赤外線(IR)通信は、マイクロコントローラ44に接続される2つの回路、すなわち、IR送信用のIR送信機(送信機)49及びIR受信用のIR受信機(受信機)40を使用して実現されるのが好ましい。
【0099】
リモートリーダ1の感圧タッチパネル8は、タッチパネルインタフェース41を介してマイクロコントローラ44と通信を行なう。スマートカードインタフェース42は電気接点7に接続する。
【0100】
システム内プログラミングインタフェース52もマイクロコントローラ44に接続される。これにより、マイクロコントローラフラッシュメモリ46を介してファームウェアを用いてマイクロコントローラ44をプログラミングできるようになる。ファームウェアについては、第6.0節を参照して本文書で詳細に後述する。
【0101】
ここでは、リモートリーダ1の内部構成を更に詳細に説明する。
【0102】
3.1 低電力モードの寿命
電源制御装置50は、低電力「スリープ」モード及びアクティブモードの2つの電力モードを提供するように動作可能である。低電力モードの寿命は、バッテリ53の寿命を年単位で表したものである。リモートリーダ1が機能しておらず、低電力モードにあるとき、寿命は2年間よりも長くなる可能性がある。
【0103】
リーダ1がスリープモードにあるときにユーザがタッチパネル8を押下する場合、リモートリーダ1はスリープモードから抜け出て、CPU45は接触座標を計算すると共に赤外線送信によりシリアルメッセージを送信する。バッテリ53は100,000回を超えるボタン押下の電流供給要求に対して使用可能状態を維持するのが好ましい。
【0104】
3.2 耐用寿命
耐用寿命は、リモートリーダ1が使用可能状態を維持することが予想される期間として定義され、バッテリの交換は含まない。耐用寿命は平均故障間隔(MTBF)の数値に関連し、通常、加速寿命試験を使用することで統計的に得られる。従って、リモートリーダ1の耐用寿命は5年よりも長くなる可能性がある。
【0105】
3.3 マイクロコントローラ
リモートリーダ1のマイクロコントローラ44は、4096バイトのフラッシュメモリ46及び128バイトのランダムアクセスメモリ47と共に8ビット中央CPUを有する。マイクロコントローラ44は3から5ボルトの供給電力で動作するのが好ましく、フレキシブルオンボードタイマ、割込み源、8ビットA/Dコンバータ(ADC)、クロックウオッチドッグ、及び低電圧リセット回路を有する。また、マイクロコントローラ44は大電流出力ピンを有し、わずかな外部接続のみで回路中にプログラムできるのが好ましい。
【0106】
3.4 クロックソース
リモートリーダ1用のメインクロックソース48は、内蔵の平衡コンデンサを有する3ピン4.91MHzセラミック共振子であるのが好ましい。周波数許容範囲は0.3%である。この許容範囲は水晶ほど良くはないが、シリアル通信に適しており、水晶よりも小型で安価である。
【0107】
3.5 ビーパ(Beeper)
ビーパ51はリモートリーダ1の中に含まれており、カードエントリ状態について及びボタン押下に対して可聴のフィードバックを与える。ビーパ51は圧電セラミックディスク型であるのが好ましい。
【0108】
3.6 赤外線通信
上述のように、赤外線(IR)通信は、IR送信用のIR送信機49及びIR受信用のIR受信機40の2つの回路を使用して実現されるのが好ましい。この2つの回路40及び49は、リモートリーダ1内のプリント回路基板(例えば、図47のPCB4801)上で組み合わされるのが好ましい。プリント回路基板4801は、4方向フラットプリントケーブルによりマイクロコントローラ44に接続することができる。送信時に必要なサージ電流を提供するために、PCB4801には大型のバルク減結合コンデンサが必要とされる。
【0109】
3.7.1 赤外線送信
IR送信は、IR送信機49の一部を形成する赤外線発光ダイオード(LED)(例えば、図47(a)のLED4800)により行なわれるのが好ましい。
【0110】
3.7.2 赤外線受信
IR受信機40は、赤外線フィルタ、PINダイオード、増幅器、及び弁別回路と共に単一のデバイスへと統合されるのが好ましい。受信されるシリアル情報は、このデバイスからマイクロコントローラ44の入力ポートへと直接進む。このポートは、データの受信時に割込みを発生し、迅速な格納及び入力信号の処理が可能になるようにプログラムすることができる。
【0111】
3.8 CPU/メモリカードインタフェース
リモートリーダ1は、国際標準化機構(ISO)標準7816−3及びISO7810により定義されるスマートカード10をサポートできるのが好ましい。3Vメモリカード及び5Vメモリカードと同様に、T=0プロトコル及びT=1プロトコルを有する3VCPUカード及び5VCPUカード(すなわち、内蔵のマイクロプロセッサを有するカード)もサポート可能である。
【0112】
カード10とマイクロコントローラ44とを接触させるのに使用される電気接点7は、8つのワイピング接点及び1つの「カードイン」スイッチを有する表面実装型コネクタであるのが好ましい。ISOの基準によると、以下の信号が提供されなければならない:
・ピン1−VCC−供給電圧、
・ピン2−RST−リセット信号、カードへの2進出力、
・ピン3−CLK−クロック信号、カードへの2進出力、
・ピン4−RFU−未使用、常時未接続、
・ピン5−GND−グランド、
・ピン6−VPP−プログラミング電圧、不要、GND、VCCへの連結又は開放、
・ピン7−I/O−データI/O、双方向信号、及び
・ピン8−RFU−未使用、常時未接続
RSTピン及びI/Oピンはマイクロコントローラ44に直接接続されるのが好ましい。電源を除く全てのピンには、静電気放電の問題を回避するために、シリーズターミネーションダイオード及び過度電圧抑制器ダイオードが備わっている。
【0113】
3.9 CPUカード電源
上述のように、マイクロコントローラ44が動作するには3V〜5Vの電源が必要である。5V電源は、調整5VチャージポンプDC−DCコンバータチップの形態の電源制御装置50を用いてバッテリ53として動作する3Vコイン型リチウム電池から生成することができる。
【0114】
3.10 タッチセンシティブインタフェース
上述のように、リモートリーダ1の感圧タッチパネル8は、タッチパネルインタフェース41を介してマイクロコントローラ44と通信を行なう。タッチパネルインタフェース41はタッチパネル8上の接触の位置に従ってアナログ信号を提供する。このアナログ信号はマイクロコントローラ44に送信される。
【0115】
接触座標の計算には、下側及び左側のタッチパネル8の接点(不図示)がマイクロコントローラ44上のA/Dコンバータの入力へと接続されることが必要である。
【0116】
タッチパネル8への接触は、好ましくは、リモートリーダ1をスリープモードからウェイクアップするのに使用することができる。左側の画面接点から図示されるスリープ中のウェイクアップポートまで抵抗接続することでこの機能が提供される。尚、システム内プログラミング中に最大8ボルトが割込み要求ピン(IRQ)と呼ばれるマイクロコントローラ44上のピンに印加される可能性があるので、デバイスの損傷を防止するためにクランピングダイオードをこのピンに取り付ける必要がある。この例では、タッチパネル8の押下を検知するのに必要なバイアスを実際に提供するのはIRQピン上の内部プルアップである。
【0117】
3.11 バッテリ
上述のように、リモートリーダ1はバッテリ53を使用する。5Vコイン型リチウム電池をバッテリ53として使用し、リモートリーダ1の全回路に電力を供給することができる。
【0118】
3.12 システム内プログラミング
マイクロコントローラはシステム内プログラミング(ISP)オプションをサポートする。リモートリーダ1においては、システム内プログラミングインタフェース52が使用され、ファームウェアを用いたマイクロコントローラフラッシュROMメモリ46のプログラミングなどのマイクロコントローラ44のプログラミングが実行される。
【0119】
3.13 プリント回路基板及び相互接続
リモートリーダ1は、リーダ4401の1つのPCB4801の代りに、以下に示すような2つのプリント回路基板(PCB)を含むことができる:
(i)赤外線ダイオードを保持し、FET及び受信機を駆動する赤外線(IR)PCB、及び
(ii)上述の他の全ての構成要素40から53を保持するメインPCB(例えば、図47(a)のPCB4801)
上述の双方のPCBボードは、標準のFR4、1.6mmPCB材料を使用する両面設計であるのが好ましい。完成品のPCBの厚さは重要であるので、メインPCBは表面実装型部品を利用するのが好ましく、部品は最大約3mmの高さに制限されるのが好ましい。
【0120】
IR PCBはスルーホール部分を使用することができるが、部品の高さには厳しい制限が課せられるのが好ましい。2つのPCBの相互接続は、カスタムデザイン4方向プリントケーブル(FCA)を介して行なわれる。これは、タッチパネル8とインタフェースをとるのに使用される同一部品の表面実装型FCAコネクタを介して2つのPCBとインタフェースをとる。
【0121】
3.14 低電力モード
リモートリーダ1が短時間の間使用されない場合、バッテリの寿命を浪費しないために事前にプログラムされたファームウェアが装置を低電力モードにするのが好ましい。低電力モードでは、全ての電流を消費する構成要素への供給電力が停止され、マイクロコントローラ44の各ポートは安全なスリープ状態に設定され、クロック48は停止される。この状態で、リモートリーダ1の電流消費は5μA未満である。PチャネルFETを使用して電流を消費する構成要素への電力供給を制御することができる。
【0122】
低電力モードからリモートリーダ1をウェイクアップするには以下に示すような3つの代替の好適な方法がある:
・タッチパネル8への接触、
・カードレセプタクル4へのカードの挿入、及び
・バッテリ53の取外し及び再挿入
カード挿入ウェイクアップにより、装置が低電力モードにあるか否かに関わらず、リモートリーダ1はカードが挿入されるときには常にビープ音を発することができる。接触/カード挿入ウェイクアップは、マイクロコントローラ44上に図示されるようにIRQピンにより処理される。新規の接触又はカード挿入のみがマイクロコントローラをウェイクアップするように、このピンは「エッジトリガ」に設定されることが重要である。IRQの感度が「レベル」トリガに設定される場合、例えば、リモートリーダ1が荷物の中に詰められているときにタッチパネル8が偶然押下されたままの状態になると、リモートリーダ1は低電力モードに入ることができない。
【0123】
3.15 割込み及びリセット
リモートリーダ1用のマイクロコントローラ44のファームウェアは、2つの外部割込み原因及び1つの内部割込み原因を使用する。低電力モードのウェイクアップの場合、外部割込みはIRQピンから発生する。内部割込みはタイマのオーバーフローにより引き起こされ、種々の外部インタフェースの時間を調整するのに使用される。これらの割込みは事前にプログラムされたファームウェア手順により行なわれる。
【0124】
マイクロコントローラには以下に示すように4つの可能なリセット原因が存在する:
・2.4Vでの低供給電力リセット、
・不正なファームウェア演算コードリセット、
・ファームウェアがループに入り込んだ場合のコンピュータ正常動作(COP)リセット、及び
・システム内プログラミング(ISP)が開始されるときにリセットピンに対して強制されるISPリセット
【0125】
4.0 カードデータ形式
上述のカード10に対するデータ形式を以下の段落で説明する。図4に関連して説明した制御カード10Bのようなメモリカードの場合、後述する形式に従ったデータはカードに直接コピーされることになる。上述のCPUカードの場合、後述する形式に従ったデータは、ファイルとしてカードのCPUのファイルシステムへとロードすることができる。
【0126】
上述のカード10は、種々のカード特性及びカード上に印刷された任意のユーザインタフェース印を記述するデータ構造を格納するのが好ましい。また、カード10はカード、ベンダ、及びサービスについての情報などの属性を指定するグローバル特性を含むことができる。ユーザインタフェースオブジェクトが存在する場合には、カード10の表面の領域と関連付けるべきデータを指定する。
【0127】
ここで説明するユーザインタフェースは、所定の領域又はカード10の表面に直接転写されたアイコン表現をコマンド又はアドレス(例えば、Uniform Resource Locator(URL))と関連付けるマッピングデータを表す。マッピングデータは、一般的に、カード10上のユーザインタフェース要素(例えば、所定の領域)のサイズ及び位置を定義する座標を含む。ここで、ユーザインタフェース要素という用語は、通常、カード10上の印を指すが、ユーザインタフェースオブジェクトという用語は、通常、特定の印に関連するデータを指す。しかし、これらの用語は以下の説明において区別なく使用される。
【0128】
ユーザインタフェースオブジェクトはカード10に直接格納されるのが好ましい。また、ユーザインタフェースオブジェクトはカード10自体ではなく、システム600に格納することもできる。例えば、カード10はオンカードメモリを介して固有の識別子であるバーコード又は磁気ストリップを格納することができる。この固有の識別子は、ほぼ同様のユーザインタフェース要素及びレイアウトを有するカード10に固有のものである。固有の識別子は、ユーザの押下の結果タッチパネル8から判定された座標と共にリーダ1によりシステム600のコンピュータ100又はセットトップボックス601に送信することができる。コンピュータ100、セットトップボックス601、又はサーバ150上に格納されたユーザインタフェースオブジェクトを有するシステム600は、カード10上のユーザインタフェース要素により表される所望の機能を提供するために、判定された座標からカード10及びユーザ押下と関連付けられたサービスに関連する対応するコマンド、アドレス、又はデータへのマッピングを実行することができる。この例では、上述のユーザにより選択された印に関連するデータは、所望の印に重なるタッチパネル8の部分をユーザが押下した結果リーダ1により判定される座標の形態をとる。
【0129】
上述のカード(例えば、10)において、カード10により格納されるデータはカードヘッダを含み、このカードヘッダには以下の各節で説明する0個以上のオブジェクトが続く。
【0130】
4.1 カードヘッダ
図11は、スマートカード10に格納されたカードヘッダ1100のデータ構造を示す。ヘッダ1100は、各々が4バイトのデータを表す複数の列1101を含む。データは「ビッグエンディアン」形式であるのが好ましい。完全なヘッダは20バイト長であり、以下のフィールドを含む(詳細は図12に記載):
(i)カードを有効なメモリカードとして指定する定数を含むマジックナンバーフィールド1102(例えば、このマジックナンバーフィールド1102は、特定の製品に帰属するプロプライエタリカードが使用されていることを確認又は検証するのに使用することができる)、
(ii)カードレイアウトの下位のバージョンと互換性のあるリーダにより読むことができないレイアウトの変更を指定する各バージョンの増加分を含むバージョンフィールド1103、
(iii)予約フィールド1104(このフィールドは今後の使用のために予約されている)、
(iv)カード用のフラグを含むフラグフィールド1105(図13参照)、
(v)サービス1106及びサービス固有1107フィールドの2つのフィールドを含む区別用識別子フィールド1110(サービスフィールド1106は対応するカードのサービスを識別し、サービス固有フィールド1107はオプションとしてサービス固有値を含む)、
(vi)ヘッダに続くオブジェクトの数を表す数値を含むオブジェクト数フィールド1108(このフィールドは0に設定することもできる)、及び
(vii)チェックサム自体を除くカード上の全てのデータのカードチェックサムを含むチェックサムフィールド1109
【0131】
図12は、図11を参照して説明した種々の(数値)フィールドの内容の記述を提供する。特に、区別用ID番号フィールド1110は8バイトの区別用識別子を具備する。区別用識別子は、データの単位である2つの部分、すなわち、サービス識別子及びサービス固有識別子を含む。区別用識別子は、サービス識別子が区別用識別子の値全体のうちの5バイトを占め、サービス固有識別子が3バイトを占めるように構成されるのが好ましい。
【0132】
フィールド1106に含まれるサービス識別子は、サービス又はベンダを区別する。すなわち、例えば、サービスはカードユーザにそのサービスを提供するアプリケーションと関連付けることができる。これは、複数のアプリケーションを提供することによってカードユーザに複数のサービスを提供することができるベンダとは異なる。
【0133】
サービス識別子は使用するアプリケーション又はアプリケーションの位置(例えば、URL)を識別するための識別子となることができる。また、総称カードがシステム600A又は600Bに追加されても良く、これらのカードはサービス識別子の特殊な使用例である。総称カードは、既に実行中の現在のアプリケーションへの入力を提供するのに使用可能な特殊なサービス識別子を有するカードである。サービスの特殊値0x0000000001は「総称サービス識別子」として知られ、「総称カード」上で使用される。総称カードは既に実行中のフロントアプリケーションにデータを送信するのに使用することができる。これらのカードは、例えば、テキスト入力を任意のアプリケーションに送信するのに使用可能なキーパッド又は個人的な詳細情報を任意のアプリケーションに送信するのに使用されても良い個人情報付きのカードの代わりに使用される。
【0134】
フィールド1107に含まれるサービス固有識別子は、特定のサービスのベンダが、その特定サービスと関連付けられる所定の機能を提供するのに任意で使用することができる。サービス固有識別子の使用は、システム600上で実行中のアプリケーション304によってほぼ決まる。例えば、サービス識別子及びサービス固有識別子は、カード10に対する固有の識別子として使用することができる。この固有の識別子は、特定のサービスと関連付けられる特定の機能へのアクセスを獲得又は拒絶し、ログファイル中に固有サービス識別子を再現してその値を有する特定のカード10がサービスにアクセスするのに使用されたことを確認又は検証できるようにし、データベース中の対応する値に合わせることができる固有の識別子を提供してサービスのユーザに関する情報(名前、住所、クレジットカード番号など)を取得するために使用することができる。
【0135】
サービス固有識別子の使用の他の例として、カード10の配布のメカニズム又は様式(郵便、バスターミナルの売店、列車内での配布など)に関する情報の提供を含むことができる。更に、サービス固有識別子は、サービスがアクセスされたときにシステム600にどのデータがロードされるべきかを識別することができる。
【0136】
以上の説明はサービス固有識別子の可能な使用法又は適用例を網羅したリストではなく、可能な適用例の少数のサンプルに過ぎない。フィールド1107のサービス固有識別子にはその他にも多くの適用例がある。
【0137】
4.1.1 カードフラグ
図11のヘッダ1100のフラグフィールド1105は以下のような3つのフラグを含んでも良い:
(i)ビープ停止、
(ii)移動イベントなし、及び
(iii)イベント座標なし
図13は上述の各フラグの記述を示す。上述のフラグは、各フラグの記述により定義されるように、リモートリーダ1においてスマートカード10が実行可能な機能に影響を及ぼす。図13で参照されたユーザインタフェース要素の一例はカード10上の「ボタン」である。ユーザインタフェース要素は本文書で更に詳細に後述する。
【0138】
4.2 オブジェクト
図57に示すように、図11のカードヘッダ1100の直後に、特定のカード10の各オブジェクトを定義し且つカード10上に格納されたデータの一部を形成する0個以上のオブジェクト構造5713を続けることができる。各オブジェクト構造5713は以下のような4つのフィールドを具備する:
(i)種別フィールド5701、
(ii)オブジェクトフラグフィールド5703、
(iii)長さフィールド5705、及び
(iv)データフィールド5707
データフィールド5707の構造は後述するオブジェクト種別によって決まる。
【0139】
図14は、オブジェクト構造5713の各フィールド5701、5703、5705、及び5707の記述を示す。オブジェクト構造5713のフラグフィールド5703は、非アクティブフラグを含むのが好ましい。図15は非アクティブフラグの記述を示す。
【0140】
上述のカード10A、10B、10C、及び10Dには以下に示すように5つのオブジェクト種別が提供されるのが好ましい:
(i)ユーザインタフェースオブジェクト(すなわち、カード10上のボタンを定義するデータ)、
(ii)カードデータ、
(iii)固定長データ、
(iv)リーダ挿入、
(v)操作なし、及び
(vi)操作なし(1バイト)
図16は、上述のオブジェクト種別(i)から(vi)の各々の記述を示している。
【0141】
4.2.1 ユーザインタフェースオブジェクト
各ユーザインタフェースオブジェクトは、カード10上の矩形領域とユーザがパネル8のカード10の対応する矩形領域の上にある領域に接触するときに送信される幾つかの関連データとを定義する。座標マッピングシステムの起点は、スマートカード10がISO標準メモリスマートカードであり、チップ接点18がビューアの反対方向且つカード10の底部の方向を向くように縦向きに保持されたときのカード10の左上である。このカードの向きを使用しないリーダ1の場合、正しい「ボタン」押下を通知するように四隅の点の値がリーダ1によって調整されなければならない。
【0142】
ユーザインタフェース(要素)オブジェクト構造は、以下に示すように6つのフィールドを有するのが好ましい:
(i)フラグフィールド、
(ii)X1フィールド、
(iii)Y1フィールド、
(iv)X2フィールド、
(v)Y2フィールド、及び
(vi)例えば、URL、コマンド、キャラクタ又は名前に対するユーザインタフェース要素と関連付けられるデータを通常含むデータフィールド
【0143】
図17は、先に説明したユーザインタフェースオブジェクト構造に対する上述の各フィールドの記述を示す。感圧タッチパネル8の押下は、以下のような場合に特定のユーザインタフェースオブジェクトの内側であると定義される:
(i)押下位置のX値が関連するユーザインタフェースオブジェクトのX1値以上であり、その特定のユーザインタフェースオブジェクトのX2値未満である場合、及び
(ii)押下位置の押下Y値が特定のユーザインタフェース要素のY1値以上であり、Y2値未満である場合
【0144】
ユーザインタフェース要素は重複しても良い。押下が2つ以上のユーザインタフェース要素の範囲内である場合、送信されるオブジェクトはZ順により判定される。カード上のユーザインタフェース要素の順序は、その特定のカード上の全てのユーザインタフェース要素に対するZ配列を定義する。先頭のユーザインタフェース要素は特定のカード10に対する第1のユーザインタフェース要素である。最後尾のユーザインタフェース要素はそのカード10に対する最終のユーザインタフェース要素である。これにより、非矩形の領域の定義も考慮される。例えば、「L」型のユーザインタフェース要素を定義するには、第1のユーザインタフェースオブジェクトがデータフィールドに0バイトを伴って定義され、第2のユーザインタフェースオブジェクトが第1のユーザインタフェースオブジェクトの左下にユーザインタフェースオブジェクトに重なるように定義されるであろう。
【0145】
押下の位置は「フィンゲル(fingel)」において通知される。この「フィンゲル」はフィンガー要素(画素を表す「ピクセル」に類似)を表す。フィンゲルの高さはISOメモリスマートカードの長さの1/256であり、幅はISOメモリスマートカードの幅の1/128であると定義される。各要素と関連付けられる挙動は1つ以上のフラグを用いて変更されても良い。各ユーザインタフェース要素は以下に示すように4つの関連するフラグを有するのが好ましい:
(i)ビープイネーブル反転
(ii)オートリピート
(iii)押下時データ送信禁止
(iv)リリース時データ送信禁止
図18は、各ユーザインタフェース要素フラグの記述を示す。
【0146】
4.2.2 カードデータ
カードデータオブジェクトは、特定のカードに固有のデータを格納するのに使用される。このオブジェクトに対するデータレイアウトは固定の形式をもたない。カード10がリーダ1へと挿入されるとき、カードデータオブジェクトの内容がINSERTメッセージの一部としてリーダ1から送信される。
【0147】
4.2.3 固定長データ
固定長データオブジェクトは、例えば、コンピュータ100により書き込むことが可能なカード上の固定長ブロックを定義するのに使用される。
【0148】
4.2.4 リーダ挿入
リーダ挿入オブジェクトは、特定のカードが挿入されたときにリモートリーダ1に対する命令を格納するのに使用される。これは、例えば、IRコマンドの特定の構成を使用して特定のセットトップボックス又はTVなどと送受信できるようにするべくリーダ1に指示するのに使用することができる。
【0149】
4.2.5 操作なし
操作なしオブジェクトは、特定のカード上の他のオブジェクト間の未使用のセクションを埋めるのに使用される。操作なしオブジェクトに格納されるあらゆるデータはリモートリーダ1によって無視される。カード10の端の未使用の空間は操作なしオブジェクトを用いて埋める必要がない。
【0150】
4.2.6 操作なし(1バイト)
操作なし(1バイト)オブジェクトは、完全なオブジェクト構造には小さすぎるオブジェクト間の隙間を埋めるのに使用される。これらのオブジェクトは合計しても1バイト長である。
【0151】
5.0 リーダプロトコル
リモートリーダ1は、例えば、リモートリーダ1とセットトップボックス601又はコンピュータ100との間の単方向通信及び双方向通信の双方をサポートするデータグラムプロトコルを使用する。リモートリーダ1とユーザとのインタラクションの結果、リモートリーダ1から受信するメッセージに使用される形式は、リモートリーダ1に送信される形式とは異なる形式である。
【0152】
5.1 メッセージ種別
リモートリーダ1により送信することが可能なメッセージイベント種別は少なくとも7つある。これらのイベントは以下の通りである:
・INSERT:カード10がリモートリーダ1へと挿入され、カード10が検証されると、リモートリーダ1によりINSERTイベントが生成され、関連するメッセージが送信される。このメッセージはカード10の存在を受信機(例えば、セットトップボックス601)に通知するものである。INSERTメッセージは特定の区別用識別子を含むのが好ましく、最初のインタラクションが起こるまで待たずにカード10の挿入直後にアプリケーションを開始又はフェッチできるようにする。INSERTメッセージは、この種のオブジェクトがカード10上に存在する場合、リーダ1へと挿入されるカード10からのカードデータオブジェクトの内容を含むのが好ましい。
【0153】
・REMOVE:カード10がリモートリーダ1から抜き取られると、対応するREMOVEイベントが生成され、REMOVEメッセージがリモートリーダ1と関連付けられた特定の受信機に送信される。INSERTメッセージと同様に、関連する区別用識別子がメッセージと共に送信される。抜き取られたカード10からは区別用識別子を読むことができないので、区別用識別子はリモートリーダ1のメモリ47に格納される。他の全てのメッセージが区別用識別子を必要とするが、区別用識別子が必要となるたびにカード10から区別用識別子を読むのでは遅すぎる可能性があるので、これは有用な最適化である。システム600は処理を制御する際にINSERTメッセージ及びREMOVEメッセージに依存しない。受信したメッセージが予期されるものでない場合、システム600は欠落したメッセージがあることを推定するように構成される。例えば、アプリケーションが2つの連続するINSERTメッセージを検知した場合、現在の構成では一度に2枚のカードを挿入することはできないので、第1のINSERTメッセージのカードと関連付けられたREMOVEメッセージが欠落したと想定することができる。アプリケーションは、第2のINSERTメッセージを処理する前に必要なあらゆる動作を行なうことができる。
【0154】
・メッセージの欠落が起こりうる別の例は、有線式のリーダに対してハンドヘルドの赤外線接続のリーダ1が使用される場合である。ユーザはカードの挿入又は抜き取り時にリーダを受信機に直接向けないことが多い。この問題は、連続するPRESS/RELEASEの対において区別用識別子が異なることに基づいてINSERT操作又はREMOVE操作を推定するシステム600により解消することができる。
【0155】
・BAD CARD:無効なカードが挿入される場合、リモートリーダ1はBAD CARDイベントを生成し、BAD CARDメッセージを送信するように構成されるのが好ましい。このメッセージにより、関連する受信機はユーザに対して無効なカードであることを警告すべく何らかの動作を行なうことができる。
【0156】
・PRESS:リモートリーダ1により接触が検知されるとき、PRESSイベントが生成され、PRESSメッセージが関連する受信機に送信される。PRESSメッセージは、関連するカードの詳細、押下の位置、及びその特定の位置においてユーザインタフェース要素と関連付けられたデータを含む。その位置に対して定義されるユーザインタフェース要素が存在しない場合(カード10上に定義されるユーザインタフェース要素が全く存在しない場合を含む)、関連するカードの詳細及び押下の位置を含むPRESSメッセージが送信される。PRESSイベントが生成されたときにリモートリーダ1内にカードが存在しない場合、特殊な「NO_CARD」識別子(すなわち、8バイトの0−0x00)及び押下の位置を含むPRESSメッセージが送信される。
【0157】
・RELEASE:RELEASEイベントはPRESSイベントを補うものであり、システム600のアプリケーションプログラムにPRESSが解除されたことを通知するためにRELEASEメッセージを送信することができる。全てのPRESSイベントは対応するRELEASEイベントを有するのが好ましい。リーダは複数回の押下を登録したり、あるいは、PRESSメッセージとRELEASEメッセージとの間に発生する可能性があるその他のイベントを提供したりすることができる。
【0158】
・MOVE:PRESSイベントの処理後に接触位置がある量だけ変化する場合、指(又はカードに接触するのに使用されるもの)が移動中であると想定される。MOVE EVENTが生成され、接触が解除されるまでMOVEメッセージが送信される。接触位置が静止したままであるときには、MOVEイベントは直前のMOVEメッセージを再送信することによってオートリピートする。接触が解除され、対応するRELEASEメッセージが送信されると、送信の繰り返しは終了する。PRESSイベント及びRELEASEイベントとは異なり、MOVEイベントと関係するユーザインタフェースオブジェクトは存在しない。
【0159】
・LOW BATT:リモートリーダ1中のバッテリ53の電力が低下しているとき、LOW BATTイベントが生成され、LOW BATTメッセージが送信される。このメッセージは、ユーザとのインタラクションの後にメッセージがシステム600のその他の部分により受信される可能性を高めるために送信される。LOW BATTメッセージの送信は、リモートリーダ1が低電力状態に入ることを妨害しない。
【0160】
5.2 データ形式
システム600において使用されるリーダプロトコルの好適なデータ形式は、固定サイズのヘッダの後に0バイト以上の長さを有することが可能な可変長のデータフィールドが続き、更にその後に8ビットのチェックサム及び補数が続く形式である。
【0161】
5.2.1 メッセージヘッダ
メッセージヘッダは固定長であることが好ましく、リモートリーダ1から送信される全てのメッセージの前に付加される。帯域幅に制約がある可能性があるので、メッセージヘッダは可能な限り小さくする必要がある。図19は、リモートリーダ1から送信されるメッセージヘッダの形式を示す。
【0162】
ベンダが特定のサービスを登録するとき、スマートカード識別機関によりサービス識別子及びサービス固有識別子をそのベンダに割り当てることができる。サービス及びサービス固有識別子は任意のカードからの全てのメッセージに対して同じである。サービス固有識別子はアプリケーションと共に使用するためにベンダにより設定されるのが好ましい。リーダ識別子も各メッセージのヘッダ中に存在する。この識別子は、例えば、マルチプレーヤゲームにおいてユーザを区別するためにアプリケーション304により使用することができる。
【0163】
図20は、以上説明したメッセージイベント種別を列挙するテーブルを示している。
【0164】
5.2.2 単純なメッセージ
幾つかのメッセージ種別は、上述のメッセージヘッダ並びにそれに続くメッセージチェックサムバイト及びその補数のみから成るという点で単純であると考えられる。例えば、BADCARDメッセージ、LOW_BATTメッセージ、及びREMOVEメッセージは単純なメッセージである。
【0165】
図21は、単純なメッセージの形式を示す。
【0166】
5.2.3 MOVEメッセージ
MOVEメッセージは、上述のメッセージヘッダ及びそれに続くリモートリーダ1のタッチパネル8上の接触位置の座標を定義する2つのフィールドから形成される。図22はMOVEメッセージの形式を示す。
【0167】
5.2.4 PRESSメッセージ及びRELEASEメッセージ
図23は、PRESSメッセージ及びRELEASEメッセージの形式を示す。PRESSメッセージ及びRELEASEメッセージは、MOVEメッセージと同様にメッセージヘッダ及び接触座標を含む。加えて、接触位置がカード上で定義されるユーザインタフェース要素と一致する場合、PRESSメッセージ及びRELEASEメッセージはユーザインタフェース要素と関連付けられるデータを送信する。このデータは可変長であり、実際のサイズは対応するカード10により定義される。接触位置がカード上で定義されるユーザインタフェース要素と一致しない場合(カード上で定義されるユーザインタフェース要素がない場合を含む)、ユーザインタフェース要素と関連付けられる0バイトのデータが送信される。リーダ1内にカード10がない場合、サービス識別子は全てが0(すなわち、0x00)に設定され、ユーザインタフェース要素と関連付けられる0バイトのデータが送信される。ユーザインタフェース要素と関連付けられたデータは、通常、カード上で定義されるユーザインタフェース要素と関連付けられたデータに対応するが、カード10又はリーダ1での処理により変更又は生成されても良い。
【0168】
図24は、システム600内の上述のメッセージの流れを示すデータフロー図である。図24に示すように、カードヘッダ1100及びオブジェクト構造5713は、リモートリーダ1のCPU45により読み取られる。CPU45は対応するINSERTメッセージ、REMOVEメッセージ、PRESSメッセージ、RELEASEメッセージ、MOVEメッセージ、BADCARDメッセージ、又はLOW BATメッセージをI/Oデーモン300を介してイベントマネージャ301に送信する。以下で更に詳細に後述するが、イベントマネージャ301は21種類のコアメッセージを有し、これらのメッセージはML302、ランチャ303、及びアプリケーション304との間で送受信される。
【0169】
5.2.5 INSERTメッセージ
INSERTメッセージは上述のメッセージヘッダ及び挿入されたカード10からのカードデータオブジェクトの内容から形成される。図21AはINSERTメッセージの形式を示す。
【0170】
6.0 リーダファームウェア
6.1 概要
マイクロコントローラ44は内蔵の不揮発性メモリ46を有し、この不揮発性メモリ46は詳細に後述するファームウェアを用いてプログラムすることができる。マイクロコントローラ44及び周辺ハードウェア(コンピュータ100など)と協働するファームウェアは、リモートリーダ1の機能的要求を指図することができる。
【0171】
6.2 コード種別
リモートリーダ1のユーザに対する費用を最小限に抑えるためには、リモートリーダ1上のメモリを最小限にするのが好ましい。従って、リモートリーダ1用に作成されるアプリケーションプログラム(すなわち、ファームウェア)は可能な限り小規模且つ高速にしなければならない。
【0172】
6.3 リソース制約条件
マイクロコントローラ44は以下のような特徴を有する:
6.3.1 不揮発性メモリ
フラッシュメモリ46は4096バイトのフラッシュROMを有するように構成され、ファームウェア格納用に利用することができる。フラッシュROMは再プログラム可能であるが、大量生産の場合、マスクROM部品を利用することができる。
【0173】
6.3.2 ランダムアクセスメモリ(RAM)
RAM47はファームウェアにより使用される128バイトのRAMとして構成される。
【0174】
6.4 割込み
リモートリーダ1は、マイクロコントローラ44がサポートする数多くの割込み原因のうちの2つを使用する。これらの割込みは以下に示すように説明することができる:
6.4.1 受信データ割込み
赤外線(IR)シリアルデータ受信機は、一般的に、入力データを受信すると立下り端を生成する。このデータは可能な限り迅速にサンプリング・バッファリングされる必要がある。マイクロコントローラ44の1つのポートは、立下り端で割込みを開始することができる入力タイミングキャプチャピンの役割を兼ねる。
【0175】
6.4.2 タイマオーバフロー割込み
マイクロコントローラ44は、オーバーフローしたときに割込みを発生するようにプログラム可能な自走16ビットタイマを有する。4.91MHzクロックソース及びプリスケール係数64の場合、3.41秒ごとの割込みになる。割込みサービスルーチンは、好ましくは、約1分の休止の後に低電力モードでのサスペンド状態を引き起こすカウンタを増分する。
【0176】
6.5 リセット
マイクロコントローラ44は5つのリセットソースをサポートするが、リモートリーダ1は全てのリセットリソースを使用するように構成されるのが好ましい。これらのリセットリソースは以下のように説明することができる:
6.5.1 パワーオンリセット(POR)
PORリセットは新規のバッテリがリモートリーダ1に取り付けられると開始される。マイクロコントローラ44はパワーオン状態を検知しリセットを生成する回路を含む。
【0177】
6.5.2 低電圧禁止(LVI)リセット
LVIリセットは、供給電圧が2.4ボルトを割ったことをマイクロコントローラ44内の回路(不図示)が検知すると開始される。この種のリセットが発生するとリセット状態レジスタ(RSR)中のフラグが設定され、初期化ルーチンはバッテリ53が切れかけていると推定することができる。例えば、赤外線データの送信中、データがパルス状に送信されると共に赤外線LEDは大電流を消費する。バッテリ53が切れると、送信中に供給電圧は2.4ボルトの閾値を割ってLVIリセットを引き起こす可能性がある。リセット後、バッテリ53の電圧は回復し、LVIリセットは次の大電流ドレインまで発生しない。これにより、ユーザによるバッテリ53の交換を促すことができるように、リモートリーダ1にはバッテリ53の消耗を関連するセットトップボックス又はリモート機器にフラグを立てて通知する機会が与えられる。
【0178】
6.5.3 コンピュータ正常動作(COP)リセット
COPリセットはマイクロコントローラ44が特定の動作を異常に長い時間実行したままでいる場合、マイクロコントローラ44をリセットするように構成される。COP回路はオーバーフローする許可が得られる場合にリセットを生成するカウンタの形態をとる。COPレジスタはCOPリセットを回避するために所定の時間間隔で書き込まれなければならない。
【0179】
6.5.4 不正アドレス/演算コードリセット
不正アドレス/演算コードリセットは、マイクロコントローラ44が所定の範囲外のアドレス及び所定の条件に合致しない演算コードに遭遇する場合に生成される。このリセットは停止することができず、コードデバッギング中にのみ出現するべきである。
【0180】
6.5.5 ハードウェアリセット
ハードウェアリセットは通常動作中にマイクロコントローラ44の「リセット」ピンをローに駆動することによって生成される。また、マイクロコントローラ44が低電力モードにある場合、割込み要求(IRQ)ピンの立下り端もハードウェアリセットを生成する。このリセットはファームウェアにおいてマイクロコントローラ44を低電力モードからウェイクアップするのに使用されるメカニズムである。IRQピンがこの機能に適しているが、それは、リセットピンのようにレベルを感知するのではなく、端のみを感知するように構成することができるからである。
【0181】
6.6 メモリカード/CPUカードインタフェース
ファームウェアは、集積回路プロトコル(例えば、I2Cプロトコル)を使用するメモリカード周辺装置のみをサポートするのが好ましい。また、ファームウェアはCPUカード形式をサポートすることができる。
【0182】
6.7 電力消費
ファームウェアはバッテリ53の寿命を伸ばすのに重要な役割を果たす。マイクロコントローラ44が実行する全ての動作は、可能な限り迅速にして電力の消費を可能な限り抑えるように最適化される。リモートリーダ1がある時間(例えば、1分)非アクティブ状態であると、マイクロコントローラ44は低電力モードでサスペンドし、バッテリの寿命を更に伸ばす。低電力モードは通常動作モードの約1/1000の電流を消費するので、このモードでの効率的なサスペンドが非常に望ましい。ファームウェアは、低電力モード中マイクロコントローラ44のポートの状態を制御する。
【0183】
6.8 デバイスプログラミング
マイクロコントローラ44は、マイクロコントローラ44内の内蔵モニタによりサポートされるシステム内プログラム(ISP)機能を使用してプログラムすることができる。モニタコードは、通常、メーカにより工場で設定されており、変更することができない。
【0184】
特定のハードウェアに対するマイクロコントローラ44のプログラミングは、インサーキットシミュレータ(ICS)キット及びモニタモードダウンロードケーブルを使用して実行することができる。このケーブルは、マイクロコントローラ44のVCCピン、GNDピン、RSTピン、IRQピン、及びPRB0ピンを使用する。プログラムするソースコードは、例えば、ICSハードウェアに対するコンピュータシリアルポート及びマイクロコントローラ44のピンに対するダウンロードケーブルを介してWindows(登録商標)95開発環境から供給することができる。このプログラミング方法はファームウェア開発/検査には理想的であるが、大量生産の場合は変更しても良い。マイクロコンピュータにおいてはモニタモードプログラミングモデルが好ましく、生産用の埋込み型プログラミングジグを使用することができる。生産ISPを考慮して信号をプログラムするための検査ポイントを提供することができる。ファームウェアがマイクロコントローラ44へとマスクプログラムされる場合、デバイスプログラミングは必要とされない。
【0185】
6.9 ファームウェアプログラミングシーケンス
ローカルコンピュータ100に接続されて動作中のリモートリーダ1を参照して、ファームウェアのプログラミングを説明する。
【0186】
6.9.1 メインループ
図25は、ソフトウェアアーキテクチャ200を組み込むシステム600のリモートリーダ1により実行される読取り方法2500を示すフローチャートである。方法2500は、上述のように、リセットイベントの発生後に開始される。方法2500はCPU45により実行される。図25の方法は「一定ペースのループ」状に構成される。すなわち、方法2500は10ミリ秒の遅延を生成するルーチンによりペース設定される。この遅延は、割込みの処理に十分な待ち時間を提供しながら必要なルーチンに適切なサービスを与える。
【0187】
第1のステップ2600において、初期化ルーチンがCPU45により実行される。初期化ルーチンは構成レジスタを初期化するために実行されるものであり、図26のフローチャートを参照して後述する。方法2500は次のステップ2501へと続く。ステップ2501において、コンピュータ正常動作(COP)レジスタがクリアされるが、これは、ファームウェアが循環ループに入り込んでいないことを示す。次のステップ2700において、特定のスマートカード10の存在及び有効性の変化をチェックするためにCPU45によりチェックカードプロセスが実行される。チェックカードプロセスについては、図27を参照して以下で詳細に説明する。方法2500は次のステップ2800へと続く。ステップ2800において、ユーザによるタッチパネル8の接触をチェックするためにCPU45により走査タッチパネルプロセスが実行される。次のステップ2900において、CPU45により10ミリ秒待機ルーチンが実行され、方法2500はステップ2501へと戻る。
【0188】
6.9.1 初期化プロセス
上述の5つのソースのうちのいずれか1つによるリセット後、全ての構成レジスタは正しい初期化を必要とする。LVIリセットが受信された場合、「バッテリ切れ可能性」フラグが設定される。図26は、ソフトウェアアーキテクチャ200を組み込むシステム600を初期化する方法2600を示すフローチャートである。方法2600はCPU45により実行されるものであり、ステップ2601で開始される。ステップ2601において、全てのレジスタが所定のデフォルト状態へと初期化される。次のステップ2602において、CPU45によりチェックが実行され、リセットがLVIリセットであるか否かが判定される。ステップ2602においてLVIリセットでない場合、方法2600は終了する。LVIリセットの場合、方法2600はステップ2603へと進む。ステップ2603において、バッテリ切れ可能性フラグが設定され、方法2600は終了する。
【0189】
6.9.2 チェックカードプロセス
図27は、ソフトウェアアーキテクチャ200を組み込むシステム600のカード10をチェックする方法2700を示すフローチャートである。上述のように、方法2700はリモートリーダ1においてスマートカード10の存在及び有効性の変化をチェックし、それに従って応答する。方法2700はCPU45により実行されるものであり、ステップ701で開始される。ステップ701において、スマートカード10がリモートリーダ1へと挿入される場合、方法2700はステップ702へと進む。ステップ702において、カード10が新規のカードである(すなわち、それ以前の状態ではリーダ1にカードが存在しなかった)場合、方法2700はステップ703へと進む。新規のカードでない場合、方法2700は終了する。次のステップ703において、「マジックナンバー」フィールド及び「チェックサム」フィールドがカード10のメモリ19に格納されたカードヘッダから読み取られ、適正さがチェックされる。「マジックナンバー」及び「チェックサム」が適正である場合、方法2700はステップ704へと進む。方法2700はステップ704へと続く。ステップ704において、区別用識別子がカードヘッダから読み取られ、「移動イベントなし」フラグ及び「イベント座標なし」フラグが設定される。カードデータが存在する場合には、それもこのステップ704においてカードから読み取られる。次のステップ705において、カードデータが存在する場合はそのカードデータも含むINSERTメッセージがコンピュータ100に送信され、CPU205により処理される。ステップ706において、「ビープ」が鳴って方法2700は終了する。
【0190】
ステップ703において「マジックナンバー」フィールド及び「チェックサム」フィールドが適正でない(すなわち、カード10が有効でない)場合、方法2700はステップ710へと進む。ステップ710において、ビープ停止フラグ、移動イベントなしフラグ、及びイベント座標フラグが設定される。次のステップ711において、BAD CARDメッセージがコンピュータ100に送信され、CPU205により処理される。ステップ712において、「ブープ(boop)」が鳴って方法2700は終了する。
【0191】
ステップ701において、スマートカード10がリモートリーダ1に挿入されていない場合、方法2700はステップ707へと進む。ステップ707において、これがリセット後のリーダ1の最初の動作である場合、方法2700は終了する。最初の動作でない場合、方法2700はステップ708へと進む。ステップ708において、「ビープ停止」フラグ、「移動イベントなし」フラグ、及び「イベント座標なし」フラグが設定され、メモリ47に格納される区別用識別子が「NO_CARD」に設定される。次のステップ709において、REMOVEメッセージがコンピュータ100に送信され、CPU205により処理される。方法2700はステップ709の後に終了する。
【0192】
6.9.3 走査タッチパネルルーチン
図28は、ソフトウェアアーキテクチャ200を組み込むシステム600のリーダ1のタッチパネル8を走査する方法2800を示すフローチャートである。上述のように、走査タッチパネルルーチンはカードボタン押下と同等のタッチパネル接触をチェックし、それに従って応答する。方法2800はCPU45により実行されるものであり、ステップ801で開始される。ステップ801において、パネル8が触れられている場合、方法2800はステップ802へと進む。パネル8が触れられていない場合、方法2800はステップ812へと進む。ステップ812において、パネル8が以前に触れられていた場合、方法2800はステップ813へと進む。以前に触れられていなかった場合、方法2800は終了する。
【0193】
ステップ813において、「ビープ停止」フラグ、「移動イベントなし」フラグ、及び「イベント座標なし」フラグが設定される。ステップ814において、メッセージ種別がRELEASEに設定され、方法2800はステップ805へと進む。
【0194】
方法2800はステップ802へと続く。ステップ802において、接触がなかった状態以来の初めての接触の認知である場合、方法2800はステップ803へと進む。次のステップ803において、CPU45はステップ703の結果をチェックすることによって、不良カードがリーダ1へと挿入されたか否かを判定する。不良カードがリーダ1へと挿入された場合、方法2800はステップ815へと進む。ステップ815において、BAD CARDメッセージがコンピュータ100に送信され、メモリ206に格納され、方法2800は終了する。ステップ803において、ステップ703の結果をチェックすることによってカードが有効である、あるいは、ステップ701のチェックによってリーダ1にカードが挿入されていないと判定された場合、方法2800はステップ804へと進む。ステップ804において、図19のメッセージヘッダ中のメッセージ種別がPRESSに設定される。次のステップ805において、CPU45はタッチパネルインタフェース41を介して接触座標(すなわち、ユーザ押下位置のXY座標)を判定する。次のステップ807において、オフセット機能及びスケール機能が座標に適用される。オフセット機能及びスケール機能は、タッチパネル8の座標空間をカード10の座標空間へとマップする。方法2800は次のステップ807へと続く。ステップ807において、CPU45がチェックステップ701により送信されたメッセージがMOVEである、及び/又は、カードがリーダ1に挿入されていないと判定する場合、方法2800は直接ステップ809へと進む。それ以外の場合、方法2800はステップ808へと進み、X1値、Y1値、X2値、及びY2値が接触座標の位置する範囲を形成する最初のユーザインタフェース要素を探し出すためにカード10のメモリ19が検索され、一致するユーザインタフェース要素と関連付けられたデータがカード10から読み取られる。ステップ809において、メッセージが任意のデータと共に関連するコンピュータ100に送信され、コンピュータ100のCPU205がそのメッセージを処理する。方法2800は次のステップ2811へと進む。ステップ2811において、ビープ音が鳴って方法2800は終了する。
【0195】
ステップ802において、接触がなかった状態以来の初めての接触の認知でない場合、方法2800はステップ816へと進む。ステップ816において、ステップ801で検知された接触が移動である場合、方法2800はステップ817へと進む。移動でない場合、方法2800は終了する。ステップ817において、メッセージ種別がMOVEに設定され、方法2800はステップ805へと進む。例えば、MOVEメッセージは図19及び図22により定義されるような接触位置のXY座標と共に送信することができ、PRESSメッセージ及びRELEASEメッセージは図19及び図23により定義されるような接触位置のXY座標及びユーザインタフェースオブジェクト(すなわち、印14のうちの1つ)と関連付けられるデータと共に送信することができる。ステップ807において、メッセージがMOVEであると判定された場合、ステップ809において、CPU45はコンピュータ100にMOVEメッセージを送信する。CPU205はXY座標をカーソル情報として処理し、ビデオディスプレイ101に表示されるカーソルを移動させる。この場合、次のRELEASEメッセージはカーソル位置で表示されるオブジェクトを選択する(例えば、プログラムを実行する、項目を選択する、又はURLをロードする)コマンドとして解釈することができる。更に、イベント座標なし(図13参照)がカード10に設定されている場合、リーダ1は接触の位置のXY座標を送信せずに、ユーザインタフェースオブジェクトと関連付けられるデータをコンピュータ100又はSTB601中のイベントマネージャ301に送信しても良い。
【0196】
加えて、アプリケーション304が図17に示すようなユーザインタフェースオブジェクト構造及びステップ808のような照合機能を有する場合、リーダ1は接触位置のXY座標をアプリケーション304に送信しても良い。その結果、CPU205は同じ照合機能を実行し、ユーザインタフェースオブジェクトと関連付けられるデータをイベントマネージャ301から読み、読んだデータと関連付けられるサービス識別子1106により識別されるサービス(ゲームなど)をカードユーザに提供する。例えば、図41のステップ4205において、CPU205はメッセージのデータフィールドにデータが存在するか否かを判定する。データがデータフィールドにある場合、CPU205はデータを読み、図41の次のステップでデータの処理を行なう。データがデータフィールドに存在しない場合、CPU205はメッセージからXY座標を読み、その座標に対して照合機能を実行し、ユーザが押下した印と関連付けられるデータを取得する。また、イベントマネージャ301は、それ自体にとって利用可能なユーザインタフェースオブジェクト構造を使用してこの機能を実行することができる。
【0197】
従って、カードユーザがタッチペインl8上で指を動かすことによってリーダ1を(カード10を挿入せずに)マウスとして使用する場合、ユーザはTVディスプレイ上に表示されたSTBメニューのSTBサービスのうちの1つを選択することができる。また、カードユーザが挿入されたカード10と共にリーダ1を使用し、何らかの印14を選択する場合、ユーザはコンピュータ100又はSTB601からサービス(ゲームなど)を受信する。特に、ユーザがSTART印を選択する場合、所望のゲームをコンピュータ100又はSTB601において実行することができ、ゲーム中のオブジェクトがKICK印14の選択に従ってボールをキックする。
【0198】
カード10に対して予めカードごとのフラグ値を定義することによって、種々のカード10をユーザに提供することができる。例えば、「移動イベントなし」のフラグ(すなわち、情報)が予めカード10に設定されている場合、リーダ1はフラグに基づいてマウスとして動作しないように構成することができる。これに対し、「移動イベントなし」のフラグが予めカード10に設定されていない場合、リーダ1はフラグに基づいてマウスとして機能するように構成することができる。
【0199】
図13に示すように、リーダ1はデフォルト状態を有する。このデフォルト状態において、リーダ1は音声フィードバックを提供し、マウスとして機能し、押下イベント、押下解除イベント、及びその他のイベントに対する座標を送信する。また、リーダ1は音声フィードバックを提供せず、マウスとして機能せず、座標も送信しないデフォルト状態を提供することもできる。
【0200】
リーダ1がカードごとのフラグ値を使用して「ビープ機能」を実行するように構成される場合、リーダ1は「ビープ」を鳴らし、図27及び図28に示すフローチャートに従って方法を実行する。また、リーダ1がカードごとのフラグ値を使用して「マウス機能」を実行するように構成される場合、リーダ1はマウスとして機能し、図27及び図28のフローチャートに従って方法を実行する。更に、リーダ1がカードごとのフラグ値を使用して「照合機能」を実行するように構成される場合、リーダ1は押下イベント、押下解除イベント、及び移動イベントに対する座標を送信し、図27及び図28のフローチャートに従って方法を実行する。
【0201】
図28のステップ808のようにEM301でも照合機能が実行される。また、カード10はマウス機能及び/又は基本機能(例えば、ユーザが選択した印と関連付けられるデータをEM301に送信)のみを有するカードとして構成することもできる。このため、カードごとのフラグ値をランダムに組み合わせることによって、種々のカード10をユーザに提供することができる。
【0202】
ここで説明するように、サービス識別子1106はシステム600にとって不可欠な識別子である。少なくとも区別用識別子1110中のサービス識別子1106をEM301に送信することによって、サービスをユーザに提供することができる。
【0203】
上述のサービス固有識別子1107は、特定のアプリケーションと共に使用されるようにベンダにより設定されるのが好ましい。このため、ベンダが各カード10に対して一意的なサービス固有識別子1107を定義する場合、カード10も一意的になるであろう。サービス固有識別子1107が特定のカードが配布された手段(郵便、列車内での配布など)についての情報を提供するのに使用されている場合、サービスにアクセスするのに使用されるのがどのカードであるかの記録を提供するファイルにそのサービス固有識別子1107を加えることができる。この情報はどれほど効果的な種々の配布手段が使用されたかを後で判定する際に使用される。
【0204】
6.9.4 10ミリ秒待機プロセス
図29は、10ミリ秒待機ルーチン2900を示すフローチャートである。10ミリ秒待機ルーチン2900は10ミリ秒が経過するまでCPUサイクルを消費するようにループする。遅延プロセス2900はCPU45により実行されるものであり、ステップ901で開始される。ステップ901において、所定のプロセスカウンタがクリアされる。次のステップ902において、カウンタが増分される。ステップ903において、10ミリ秒が経過していない場合、方法2900はステップ902に戻る。経過した場合、遅延プロセス2900は終了する。
【0205】
7.0 イベントマネージャ
イベントマネージャ301は、ソフトウェアアーキテクチャ200のプロセスコンポーネントのうちの1つである。イベントマネージャ301はアーキテクチャ200の各規則を実施し、その他のプロセスコンポーネント間の整合性のある挙動を保証する。
【0206】
7.1 システムにおける役割
大半の通信はイベントマネージャ301を介して行なわれるので、イベントマネージャ301は、アーキテクチャ200の中でもディレクトリサービス311コンポーネントを除く全てのプロセスコンポーネントが直接送受信可能でなければならない唯一のコンポーネントである。イベントマネージャ301はアーキテクチャ200の各規則の実施者として機能するが、1つの別個のプログラムとして構成される必要はない。また、イベントマネージャ301は、イベントマネージャの役割の一部を実行する複数の高信頼中継器又はその他の別々のプロセスコンポーネントから形成することができる。これは、例えば、効率又は安全上の理由から行なうことができる。
【0207】
イベントマネージャ301は、I/Oデーモン300及びランチャ303などのソフトウェアアーキテクチャ200のその他の種々の部分を組み込んでも良い。イベントマネージャ301はブラウザコントローラなどのアプリケーションでさえも組み込んで良い。
【0208】
イベントマネージャ301は、直接に又は高信頼中継器を介してディレクトリサービス311を除くシステム600の全てのプロセスコンポーネントと通信することができる。これらのコンポーネントには、I/Oデーモン300、ランチャ303、及びアプリケーション304のいずれかが含まれる。イベントマネージャ301は他のプロセスコンポーネントと通信するのに任意の適切な通信方法を使用することができる。好適な通信方法は、ほぼ世界的に実現されている伝送制御プロトコル/インターネットプロトコル(TCP/IP)であるが、Unix(登録商標)ソケットなどのその他のOS特有の方法も使用することができる。プロセスコンポーネントが統合されるときには、通信するのに使用される方法は内部データの別々のスレッド間での送受信となる可能性がある。
【0209】
イベントマネージャ301は、イベントマネージャ301をキルすることが可能な、あるいは、イベントマネージャ301のCPU時間又はネットワーク帯域幅を枯渇させることが可能な他のプロセスを含む他のプロセスコンポーネントからの干渉に影響されないように構成されるのが好ましい。これにより、イベントマネージャ301は確実にシステム600の最終的な制御を維持することができる。
【0210】
7.2 内部の要求事項
イベントマネージャ301は、ポーリング(注:ポーリングはCPU負荷の関係で推奨しない)、割込み駆動型I/O、各コンポーネントを読み書きする別々のスレッドを有する方法、又は目的を達成するその他の任意の適切な方法などの方法により、アーキテクチャ200の他の全てのプロセスコンポーネント300、303、304、及び306に対して無閉塞I/Oを実行する。これにより、1つのコンポーネントの寿命が別のコンポーネントにより尽きてしまうことが確実になくなり、ユーザの待ち時間も減少する。
【0211】
また、イベントマネージャ301は、全ての入力データの有効性をチェックし、可能であれば出力前にデータを修復するように構成される。これは、高信頼コンポーネントからのデータを含む。イベントマネージャ301もフェールセーフであるのが好ましい。コンポーネント300、303、304、及び306のうちの1つから不測のデータを受信する場合、イベントマネージャ301はそのデータを処理し、完全に不可避でない限りは終了しないように構成される。
【0212】
イベントマネージャ301は、相当に長い時間実行されるように要求される可能性があり、時間が経過しても性能が低下しないことを保証するように構成される。イベントマネージャ301は、伝送メカニズムが所定のイベントマネージャプロトコル(すなわち、EMプロトコル)を使用する任意のコンポーネントとの通信において信頼性が高いことを前提とするのが好ましいが、I/Oデーモン300を介してリモートリーダ1と通信を行なうのに使用される伝送メカニズムは信頼性が低く、入力データの一部が正しくないか、あるいは、欠落している恐れがあることを前提としている。
【0213】
7.3 手順
イベントマネージャ301は、システム600の動作の一部に直接関与しているが、アーキテクチャ200のその他の動作の多くにも透過的に参加している。イベントマネージャ301は、データパケットの通過の際にこれを変更せずに使用する点で透過的である。特に、第8.0節を参照して手順を詳細に後述する。
【0214】
図30は、ソフトウェアアーキテクチャ200を組み込むシステム600により実行されるイベントの概要プロセス3010を示すフローチャートである。プロセス3010は、システム600の構成によってCPU205により実行される。プロセス3010はステップ3000で開始される。ステップ3000において、イベントマネージャ301の開始を含むシステム初期化ルーチンが実行される。ステップ3000において、I/Oデーモンも通常イベントマネージャ301と共に開始される。
【0215】
次のステップ3700において、イベントマネージャ301はランチャ303を開始させる。ステップ3300において、イベントマネージャ301はメッセージをランチャ303に渡し、ランチャ303がどのアプリケーション304を実行すべきかを判定できるようにする。ランチャ303は対応するアプリケーション304を開始させる。プロセス3010は次のステップ3400へと続く。ステップ3400において、新規のカード10がリーダ1に挿入されるときなどに現在実行中のアプリケーション304が必要とされなくなると、ランチャ303は実行中のアプリケーションの実行を終了するために実行中のアプリケーションに終了メッセージを供給する。システム600の電源が落とされる(スイッチを切られる)ときには全てのアプリケーションが終了させられる。
【0216】
図31は、イベントマネージャ301により実行されるイベントを受信する方法3000を示すフローチャートである。方法3000は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができる。方法3000はステップ3101で開始される。ステップ3101において、ランチャ303が開始される。次のステップ3103において、イベントマネージャ301はイベントを受信する。次のステップ3105において、ステップ3103で受信されたイベントがリモートリーダ1からのものでない場合、方法3000はステップ3107へと進む。ステップ3107において、コンポーネント識別子(XID)がチェックされ、必要に応じて訂正される。方法3000は次のステップ3109へと続く。ステップ3109において、イベントを送信しようとする新規のアプリケーションがそのイベントの送信を許可される場合、方法3000はステップ3111へと進む。ステップ3111において、イベントが宛先プロセスコンポーネントに送信され、方法3000はステップ3103へと戻る。送信元のアプリケーションがステップ3109においてイベントの送信を許可されない場合、方法3000はステップ3113へと進む。ステップ3113において、イベントは放棄され、方法3000はステップ3113へと戻る。
【0217】
ステップ3105において、イベントがリモートリーダ1からのものである場合、方法3000はステップ3115へと進む。ステップ3115において、イベントがBADCARDイベント、LOWBATイベント、INSERTイベント、又はREMOVEイベントの場合、方法3000はステップ3117へと進む。それ以外のイベントの場合、方法3000はステップ3119へと進む。ステップ3117において、イベントはランチャ303に渡され、方法3000はステップ3103へと戻る。ステップ3119において、区別用識別子がNO_CARD識別子である場合、ステップ3117において、対応するメッセージがランチャ303に渡される。NO_CARD識別子でない場合、方法3000はステップ3121へと進む。ステップ3121において、区別用識別子のサービス識別子部分が現在のフロントアプリケーションを判定するのに使用されるサービス識別子と比較される。サービス識別子がフロントアプリケーションを判定するのに使用されたサービス識別子と同じでなく、区別用識別子のサービス識別子部分が特殊な総称サービス識別子でない場合、方法3000はステップ3117へと進む。ステップ3117において、このメッセージはランチャ303に渡される。フロントアプリケーション判定用のサービス識別子と同じであるか、あるいは、特殊な総称サービス識別子である場合、方法3000はステップ3123へと進む。ステップ3123において、イベントはフロントアプリケーションに送信され、方法3000はステップ3103へと戻る。
【0218】
7.4 フォーカス変更
イベントマネージャ301は、現在のフロントアプリケーションに対するものでないEM_LOSING_FOCUSイベントを問題なく無視することができる。イベントマネージャ301は、フロントアプリケーションになるアプリケーション及びそのアプリケーションと関連付けられるサービス識別子に対するEM_GAINING_FOCUSメッセージに注意する必要がある。イベントマネージャ301は、同じサービス識別子を有する同じアプリケーションに対する複数のEM_GAINING_FOCUSイベント及び現在フロントアプリケーションでないアプリケーションに対するEM_LOSING_FOCUSイベントを問題なく無視することができる。無視されるメッセージは通常通りに渡される。
【0219】
7.5 リーダメッセージ
イベントマネージャ301は、メッセージを正しいコンポーネントに配布する役割も担う。イベントマネージャ301は所定のプロトコル規則に従うように構成されるが、これについては詳細に後述する。
【0220】
7.6 メッセージ送信に対する規制
イベントマネージャ301の更なる役割は、メッセージの送信に対する所定の規制を実施することである。
【0221】
8.0 イベントマネージャプロトコル
イベントマネージャプロトコル(EMプロトコル)は、ディレクトリサービス311を除くアーキテクチャ200の全てのコンポーネント間で通信を行なうのに使用されるプロトコルである。一般的に、全てのメッセージは指定受信者に渡される前にイベントマネージャ301を通過するように構成される。EMプロトコルは、例えば、伝送制御プロトコル/インターネットプロトコル(TCP/IP)などの信頼性の高い通信プロトコルの上で実現されるデータグラムベースのプロトコルである。イベントマネージャ301は、送信される全てのデータが変更されずに正しい順序で到着することを前提とするように構成される。イベントマネージャ301は、アーキテクチャ200のプロセスコンポーネント間で同期をとる信頼性の高い方法があることを前提としない。
【0222】
全てのマルチバイト値がインターネットバイト順(すなわち、ビッグエンディアン(big endian))で送信される。この例外は、各サービスを表す「区別用識別子」の値である。この値は、幾つかの1バイトから成るブロックとして送信され、常にそのように(すなわち、区別用識別子の値はバイト配列の問題のため、通常、数値として格納されることはない)扱われる。
【0223】
8.1 通信方法
イベントマネージャプロトコルは、アーキテクチャ200のコンポーネントとシステム600のハードウェアコンポーネントとの間での通信方法のように、TCP/IPを前提とするように構成されるのが好ましい。また、信頼性の高い転送を保証する既知の通信方法を使用することもできる。例えば、「UNIXソケット」などのオペレーティングシステム特有の方法も使用することができる。データは、マルチスレッドのアプリケーションなどにおける内部データ構造を直接介してプロセスコンポーネント301、303、304、及び306間で受け渡しすることができる。
【0224】
コンポーネント間の通信の代替の方法が使用されるアーキテクチャの場合、バイト配列の問題が考慮されなければならない。アプリケーションが異なるバイト配列を有するマシン上で実行することが可能であるか、あるいは、データがネットワークバイト順(全てのコンポーネントはデフォルトでこの順序を前提とする)であることを期待するコンポーネントと通信を行なうことが要求される場合、全ての対象となる通信はネットワークバイト順で行なうことができる。
【0225】
8.2 データ形式
8.2.1 基本的なデータ型
データ型に言及すべく以下の段落で使用される略語の一部は以下の通りである:
・int8: 8ビット符号付き値、
・unit8: 8ビット符号無し値、
・int16: 16ビット符号付き値、
・unit16: 16ビット符号無し値、
・int32: 32ビット符号付き値、
・unit32: 32ビット符号無し値、及び
・xid_t: 32ビット符号無し値
8.2.2 コンポーネントアドレッシング
アーキテクチャ200中の全てのアドレス指定可能なプロセスコンポーネントには、「xid」(又はコンポーネント識別子)と呼ばれる32ビット符号無し値が割り当てられる。この数値は個々のシステム600のインスタンスの範囲内では一意的である。プロセスコンポーネントの一部のxidは常に同じである。そのxidは以下の通りである:
・イベントマネージャ301:EM_EVENT_MANGER_XID
・マスタランチャ:EM_MASTER_LAUNCHER_XID
・ランチャ303:EM_FIRST_APP_XID
・ディスプレイマネージャ306:EM_DISPLAY_MANAGER_XID
xid値は1バイトの型フィールドと3バイトの識別子とに分割される。種々の型が以下の表1に示される。
【0226】
【表1】
【0227】
8.3 メッセージ種別
EMプロトコルには22個のコアメッセージがあり、これらは以下のラベルを有するのが好ましい:
・EM_NEW_LAUNCHER
・EM_KILL_LAUNCHER
・EM_APP_REGISTER
・EM_EXIT_NOW
・EM_CLOSE
・EM_APP_STARTING
・EM_APP_DYING
・EM_GAINING_FOCUS
・EM_LOSING_FOCUS
・EM_LIST_MESSAGES
・EM_LIST_APPS
・EM_SEND_MESSAGE
・EM_POST_MESSAGE
・EM_GET_MESSAGE
・EM_DELETE_MESSAGE
・EM_READER_INSERT
・EM_READER_REMOVE
・EM_READER_BADCARD
・EM_READER_MOVE
・EM_READER_PRESS
・EM_READER_RELEASE
・EM_READER_LOW_BATT
これらのメッセージについては、以下の段落で詳細に説明する。
【0228】
8.3.1 メッセージヘッダ
システム600内で送信されるメッセージは、好ましくは、以下の情報を含むヘッダ部分を有する:
version: これは、コンポーネントにより使用されるプロトコルのバージョン番号を表す。これは、常にEM_PROTOCOL_VERSIONに設定されるべきであり、EM_PROTOCOL_VER SIONはライブラリにより使用されるバージョンとしてライブラリヘッダ中に定義される。
type: これは、ヘッダが開始するメッセージ種別を表し、後述の列挙されたメッセージ種別のうちの1つに設定される。メッセージの長さにはラベルdataLengthが割り当てられる
reserved: これは、この2バイトの値が予約されていることを表し、0に設定されるべきである。
timestamp: これは、データパケットのタイムスタンプを表す。
to_xid: これは、特定のパケットの宛先xidを表す。これは、パケットの最終宛先であり、イベントマネージャが指定の最終受信者である場合はイベントマネージャにのみ設定されるべきである。
from_xid: これは、パケットの送信元xidを表す。
dataLength:これは、ヘッダに続くデータの長さを表す。この値は0となる可能性がある。異なる種別のメッセージはメッセージヘッダに続くデータに対して異なる要求事項を課す。コンポーネントは種別からメッセージの長さを想定すべきでない。メッセージの適正なサイズと異なる場合であってもdataLengthフィールドのバイト数は常に読まれ、適正でないdataLengthによってのみストリームは破損する可能性があることが保証される。
【0229】
8.3.2 EM_NEW_LAUNCHER
EM_NEW_LAUNCHERメッセージは、イベントマネージャ301が新規のランチャ303を要求するときに送信される。ソフトウェアアーキテクチャ200がマスタランチャを含む場合、このメッセージはイベントマネージャ301とこのようなマスタランチャとの間でのみ送信される。このメッセージを含むパケットは、新規のランチャがイベントマネージャ301に接続する必要があるという情報も含む。EM_NEW_LAUNCHERメッセージは以下の情報を含むのが好ましい:
port: これは、イベントマネージャ301が新規の接続の有無を聞き取っているポート番号を表す。
host: これは、イベントマネージャ301上で実行中のマシンのホスト名を表す。
【0230】
8.3.3 EM_KILL_LAUNCHER
EM_KILL_LAUNCHERメッセージは、イベントマネージャ301がマスタランチャに現在のランチャ303をキルすることを望むときに送信される。EM_KILL_ LAUNCHERメッセージと関連付けられるデータはない。
【0231】
8.3.4 EM_APP_REGISTER
EM_APP_REGISTERメッセージは、ランチャ303に対してアプリケーションが起動し、アーキテクチャ200の残りのコンポーネントにメッセージを受信する準備ができたことを通知するときに送信される。登録される前にアプリケーション304が送信するメッセージはイベントマネージャ301により破棄されることになる。
【0232】
EM_APP_REGISTERメッセージは以下の情報を含むのが好ましい:
xid: これは、アプリケーションランチャ303により割り当てられたコンポーネント識別子を表す。送信される情報の残りは、残りのフィールドが可変長であるために構造により表すことができない。xidに続くデータは、一連のヌルで終結する文字列であり、最大長は終端のヌルを除いて256文字である。この文字列は、aからzまでの小文字及び大文字、数字0から9、及び各文字(.,から_)から構成される。文字列が256文字よりも長い場合、256文字で切り捨てられる。
Application Name:これは、現在のアプリケーションを他のアプリケーションに対して識別するために使用される名前を表す。
Service Group:これは、アプリケーションがその一部となることを希望するサービスグループの1つ以上の名前を表す。
【0233】
ブラウザコントローラなどの永続的なアプリケーションは1度登録されるだけで良い。このような永続的なアプリケーションはEM_GAINING_FOCUSイベントを取得するたびに登録する必要がない。
【0234】
8.3.5 EM_EXIT_NOW
EM_EXIT_NOWメッセージは、アプリケーションが強制されて終了しようとするときにランチャ303により送信される。EM_EXIT_NOWメッセージと関連付けられるデータはない。
【0235】
8.3.6 EM_CLOSE
EM_CLOSEメッセージは、現在のセッションが終了することを示し、アプリケーションを起動状態に戻すために永続的なアプリケーションに送信される。このメッセージを受信すると、アプリケーションは入力/出力フォーカスの変更ではなく、新規のセッションの開始として次のEM_GAINING_FOCUSイベントを処理するように要求される。EM_CLOSEメッセージと関連付けられるデータはない。
【0236】
8.3.7 EM_APP_STARTING
EM_APP_STARTINGメッセージは、アプリケーションが始動しようとしているときにランチャ303によりイベントマネージャ301に送信される。EM_APP_STARTINGメッセージは以下の情報を含むのが好ましい:
xid: これは、始動しようとするアプリケーションのコンポーネント識別子を表す。
【0237】
8.3.8 EM_APP_DYING
EM_APP_DYINGメッセージは、アプリケーションが終了したときにランチャ303によりイベントマネージャ301に送信される。EM_APP_DYINGメッセージはランチャ303がアプリケーションの終了を確信した後で初めて送信される。EM_APP_DYINGメッセージは以下の情報を含むのが好ましい:
xid: これは、終了したアプリケーションのコンポーネント識別子を表す。
【0238】
8.3.9 EM_GAINING_FOCUS
EM_GAINING_FOCUSメッセージは、アプリケーション304がリモートリーダ1からの入力の受信を開始しようとするときにランチャ303によりアプリケーションに送信される。EM_GAINING_FOCUSメッセージは以下の情報を含むのが好ましい:
id: これは、アプリケーションに送信されるリモートリーダ1のメッセージの区別用識別子を表す。
Data: これは、フォーカスを受け取ろうとするときにアプリケーションに送信される追加のデータを表す。これは各サービス特有のものであり、データを解釈するのはアプリケーションの責任である。追加のデータは、バイト配列の問題に関してチェックを受けない。これはアプリケーションが対処すべきである。マルチバイトデータはアプリケーションによりネットワークバイト順で送信され、受信側アプリケーションはこの順序であることを前提とする。受信側アプリケーションがブラウザコントローラであるとき、このデータの一例はブラウザコントローラがロードするように指示されるURLである。
【0239】
8.3.10 EM_LOSING_FOCUS
EM_LOSING_FOCUSメッセージは、アプリケーション304がリモートリーダ1及びディスプレイ101からの入力/出力フォーカスを手放そうとするときに送信される。EM_LOSING_FOCUSメッセージには追加のデータはない。
【0240】
8.3.11 EM_LIST_APPS
EM_LIST_APPSメッセージは、アプリケーションがある時点において他のどのアプリケーションが実行中であるか知ることを希望するときに送信される。EM_LIST_APPSメッセージは、アプリケーションリストを含むデータフィールドを伴ってアプリケーションに戻される。このメッセージはプロセスコンポーネント301から306のうちのいずれかに宛てて送信される必要はない。イベントマネージャ301は、ヘッダのto_xidフィールドに関係なく、EM_LIST_APPSメッセージが正しいコンポーネント(通常、ランチャ303)に送信されることを確認する。どのアプリケーションを列挙すべきか決定するのが受信側コンポーネントの役割である。
【0241】
応答として使用される場合、EM_LIST_APPSメッセージは2つの形式を有する。第1の形式はEM_LIST_APPSが要求として送信されるときに使用される形式であり、第2の形式は応答として送信されるときの形式である。要求と関連付けられる追加のデータはない。
【0242】
EM_LIST_APPSメッセージは以下の情報を含むのが好ましい:
app_xid: これは、記述されるアプリケーションのxidを表す。
app_desc: これは、アプリケーションが最初に登録されるときにランチャ303に与えられる名前の文字列を表す。
【0243】
8.3.12 EM_SEND_MESSAGE
EM_SEND_MESSAGEメッセージは、システム600中の任意の2つの同時に実行されているアプリケーション間で送信することができる。アーキテクチャ200によりこのメッセージに強制される構造はないが、通信アプリケーションは共通のデータ構造について同意する必要がある。
【0244】
8.3.13 EM_LIST_MESSAGES
EM_LIST_MESSAGESメッセージは、現在の掲示板(message board)にある全てのメッセージのリストを取得するのに使用される。この掲示板はアーキテクチャ200において使用される。掲示板の詳細については、第8.4.7.1節を参照して後述することとする。EM_LIST_MESSAGESメッセージは要求形式及び応答形式を有する。要求形式と関連付けられるデータはない。応答は以下の情報を含むのが好ましい:
message_count:これは、現在掲示板にあるメッセージの数を表し、0に等しくなる可能性がある。
Messages: これは、以下の構造を有する可変サイズの構造の可変数(すなわち、message_countに等しい)を表す。
【0245】
各メッセージは以下の情報を含むのが好ましい:
message_id:これは、このメッセージのメッセージ識別子を表す。
poster_id: これは、このメッセージを提示するコンポーネントのxid(コンポーネント識別子)を表す。
mime_type: これは、このメッセージと関連付けられるデータのMultipurpose internet Mail Extension-type(MIMEタイプ)を表し、ゼロ長となり得るヌル終結文字列である。この場合でも、終端の0は存在する。
message_desc:これは、メッセージが提示アプリケーションにより提示されたときに割り当てられたこのメッセージの記述を表す。これは、終端の0を含まない最大255文字長のヌル終結文字列である。この文字列の長さは0の可能性がある。この場合でも、終端の0は存在する。
【0246】
8.3.14 EM_POST_MESSAGE
EM_POST_MESSAGEメッセージは、アーキテクチャ200において使用される掲示板に何らかのデータを提示するのに使用される。このメッセージは、サービスグループの変更があるまで続き、任意の実行中のアプリケーションによりアクセスすることができる。また、EM_POST_MESSAGEメッセージは任意の現在実行中のアプリケーションにより削除することができ、完全に信頼できるものであるとは想定されない。メッセージが提示されると、提示したアプリケーションにそのメッセージのメッセージ識別子を通知するために、アプリケーションにメッセージが戻される。このメッセージはアプリケーションによりランチャ303に送信される。アプリケーション(すなわち、メッセージを提示したアプリケーション)からのメッセージは以下の情報を含む:
message_desc:これはメッセージの記述を表す。これは、終端の0を含まない最大255文字長となり得るヌル終結文字列である。記述は0バイトとなる可能性があるが、終端の0をもたなければならない。
mime_type: これは、提示されるメッセージデータのMIMEタイプを表す。MIMEタイプは必要でないが、終端の0はなければならない。
message_data:これは、掲示板に提示されるデータを表す。
【0247】
また、アプリケーションに戻されるメッセージは以下の情報を含むのが好ましい:
message_id:これはメッセージ識別子を表し、このメッセージ識別子によりメッセージの取得又は削除を行なうことができる。
【0248】
8.3.15 EM_GET_MESSAGE
EM_GET_MESSAGEメッセージは、掲示板からメッセージを取得するのに使用される。EM_GET_MESSAGEメッセージは、コンポーネントが取得を希望するメッセージのメッセージ識別子を伴って送信され、その識別子を有するメッセージが存在しないというメッセージ又はエラーを伴ってコンポーネントに戻される。このメッセージはアプリケーション304によりランチャ303に送信される。
【0249】
メッセージの要求時に含まれる情報は以下の通りである:
message_id:これは、アプリケーションが取得を希望するメッセージのメッセージ識別子を表す。
flags: これはフラグワードである。全ての未使用ビットは0に設定されるべきである。フラグの記述は以下の表2に示される:
【0250】
【表2】
【0251】
応答は以下の情報を有する:
error: エラーが発生すると、これは以下の表3中の値のうちの1つに設定される。
【0252】
【表3】
【0253】
message_id:これは取得されたメッセージのメッセージ識別子を表す。
mime_type: これは、取得されたメッセージのMIMEタイプを表す。これはヌル終結文字列である。このメッセージと関連付けられたMIMEタイプが存在しない場合、文字列はゼロ長であるが、終端の0は存在する。
message: エラーの発生がない場合、このフィールドは掲示板に提示されるデータを含むことになる。長さはヘッダ中のdataLengthの値−エラーフィールドのサイズにより判定される。
【0254】
8.3.16 EM_DELETE_MESSAGE
EM_DELETE_MESSAGEメッセージは、掲示板からメッセージを削除するのに使用される。存在しないメッセージを削除するのはエラーではない。このメッセージはフロントアプリケーションによりランチャ303に送信される。EM_DELETE_MESSAGEメッセージは以下の情報を含むのが好ましい:
message_id:これは、削除対象のメッセージのメッセージ識別子を表す。
【0255】
8.3.17 ユーザインタフェースカードリーダメッセージ
ユーザインタフェースカードリーダメッセージはリモートリーダ1により生成され、イベントマネージャプロトコルに従うように、イベントマネージャ301によりカプセル化される。リモートリーダ1により生成されるメッセージは3種類ある。「単純な」メッセージ、「移動」メッセージ、及び「押下/押下解除」メッセージである。移動メッセージは座標が付加された単純なメッセージであり、押下/押下解除メッセージはデータ及び座標が付加された単純なメッセージである。
【0256】
8.3.17.1 単純なメッセージ
以下のメッセージが単純なメッセージである:
・EM_READER_INSERT
・EM_READER_REMOVE
・EM_READER_BADCARD
・EM_READER_LOW_BATT
これらの単純なメッセージは以下の情報を含むのが好ましい。
id: これは、リモートリーダ1により送信された区別用識別子を表し、BADCARDメッセージの場合は意味をもたない。
【0257】
8.3.17.2 移動メッセージ
EM_READER_MOVEメッセージは以下の情報を含むのが好ましい:
id: これは、リモートリーダ1により送信された区別用識別子を表し、カードなしメッセージの場合、全てが0に設定される。
X: これは、x値を表す。
Y: これは、y値を表す。
【0258】
8.3.17.3 押下/押下解除メッセージ
EM_READER_PRESSメッセージ及びEM_READER_RELEASEメッセージは以下の情報を含むのが好ましい:
id: これは、リモートリーダ1により送信された区別用識別子を表す。
X: これは、x値を表す。
Y: これは、y値を表す。
data:これは、押下又は押下解除と関連付けられる(ユーザインタフェース要素データと関連付けられる)任意のデータを表す。
【0259】
8.4 手順
以下の段落は、アーキテクチャ200の各プロセスコンポーネントが後続するメインの手順を説明する。
【0260】
8.4.1 新規のアプリケーションの開始
図32は、新規のアプリケーションを開始する方法3300の詳細を示すフローチャートであり、ランチャ303が新規のアプリケーションを開始するたびに実行される。方法3300は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができる。方法3300は第1のステップ3301で開始される。ステップ3301において、ランチャ303はサービス識別子をURLへと変換するためのマッピングを実行する。次のステップ3303において、ランチャ303はイベントマネージャのホスト名及びポート番号をランチャ303に通知するアプリケーションを取り込み、開始させる。方法3300は次のステップ3305へと続く。ステップ3305において、ランチャ303はイベントマネージャ301に開始するアプリケーションのxidを通知するEM_APP_STARTINGメッセージをイベントマネージャ301に送信する。次のステップ3307において、新規のアプリケーションはイベントマネージャ301に接続し、ランチャ303にEM_APP_REGISTERメッセージを送信する。更に、通常は、新規のアプリケーションへのフォーカス変更が存在する。
【0261】
8.4.2 アプリケーションの終了
図33は、ソフトウェアアーキテクチャ200を組み込むシステム600においてアプリケーションを終了する方法3400を示すフローチャートである。方法3400は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができる。この方法はランチャ303が実行中のアプリケーションを終了させるたびに使用される。方法3400はステップ3401で開始される。ステップ3401において、ランチャ303は実行中のアプリケーションにEM_EXIT_NOWメッセージを送信する。ランチャ303はこの時点でタイムアウトを設定し、作業を片付けて終了する機会をアプリケーションに与える。次のステップ3403において、実行中のアプリケーションは片付け作業を行ない、終了する。これに対し、アプリケーションがEM_EXIT_NOWメッセージを無視すると、ランチャ303がタイムアウトになり、アプリケーションを強制的に終了させる。ステップ3405において、ランチャ303はイベントマネージャ301にEM_APP_DYINGメッセージを送信してアプリケーションの終了を通知すると共に、あらゆる待ち状態のデータを破棄し、アプリケーションへの接続がオープンのままである場合には接続を終了すべきであると通知する。方法3400は終了する。
【0262】
8.4.3 永続的なアプリケーションのセッションの終了
図34は、ソフトウェアアーキテクチャ200を組み込むシステム600上で永続的なアプリケーションの現在のセッションを終了する方法3500を示すフローチャートである。方法3500は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができる。方法3500はアプリケーションの終了と類似しているが、アプリケーションが実際に終了する訳ではない。方法3500はステップ3501で開始される。ステップ3501において、ランチャ303は永続的なアプリケーションにEM_CLOSEメッセージを送信する。次のステップ3503において、永続的なアプリケーションは初期状態にリセットし、方法3500は終了する。これは、外部のサーバへの接続の終了、デフォルトのウェブページのロードなどを伴っても良い。永続的なアプリケーションが受信する次のEM_GAINING_FOCUSイベントは、新規のセッションの開始であると想定される。
【0263】
8.4.4 フォーカス変更
図35は、ソフトウェアアーキテクチャ200を組み込むシステム600上でフォーカス変更を実行する方法3600を示すフローチャートである。方法3600は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができる。方法3600は、アプリケーションに入力/出力フォーカスを受け取る又は失うことを通知するのに使用される。この通知はアプリケーションが終了する信号ではない。第1のステップ3601において、ランチャ303は現在入力/出力フォーカスを有するアプリケーションを変更する決定を行ない、通常はカード変更に基づいて入力フォーカスを受け取る予定のアプリケーションにEM_GAINING_FOCUSイベントを送信する。このイベントの送信はイベントマネージャ301により使用され、所定の条件に基づいてどのアプリケーションが入力/出力フォーカスを受け取るべきかが決定される。ステップ3603において、ランチャ303は前のフロントアプリケーションにEM_LOSING_FOCUSイベントを送信し、方法3600は終了する。このメッセージの重要度は低く、現在のフロントアプリケーションが変わらないときには送信されないが、EM_GAINING_FOCUSは必要である(すなわち、EM_GAINING_FOCUSイベントがブラウザコントローラ402にベースURLを通知するのに使用されるブラウザコントローラの場合)。
【0264】
8.4.5 メッセージの受け渡し(Message Passing)
アーキテクチャ200によりサポートされるアプリケーション間のメッセージの受け渡しには2種類ある。現在のサービスグループと同程度に永続的な掲示板を介する方法と2つのコンポーネントが後述するように直接相互に通信を行なう直接メッセージ方式である。
【0265】
8.4.5.1 掲示板(Message Board)
アーキテクチャ200の1つのコンポーネント(通常は、ランチャ303)が掲示板を維持するが、イベントマネージャ301にはどのコンポーネントがこの維持を行なうかが分かっている。掲示板は、掲示板を管理するプロセスコンポーネントにより識別子として32ビット符号無し数値を割り当てられたメッセージのリストから形成される。各メッセージは、テキスト記述、メッセージデータに対するオプションのMIMEタイプ、及びメッセージ自体から形成される。アプリケーションは、EM_LIST_MESSAGESメッセージを送信することによって、現在掲示板にある全てのメッセージのリストを要求することができる。この要求に対して、関連するメッセージ識別子を伴って現在掲示板にある全てのメッセージのテキスト記述が戻されることになる。アプリケーションは、必要とするメッセージのメッセージ識別子と共にEM_GET_MESSAGEを送信することによって特定のメッセージを要求することができる。掲示板のリストの取得から実際のメッセージの要求までの間にメッセージが削除される可能性もある。EM_GET_MESSAGEメッセージ応答のエラーフィールドはこれを示すように構成される。
【0266】
8.4.5.2 直接通信
2つのアプリケーションは、直接通信を使用することによって相互に任意のデータを直接送信することができる。これは、EM_SEND_MESSAGEメッセージを使用することによって一方のアプリケーションが他方のアプリケーションにデータを送信することにより実行される。2つのアプリケーションでは、このメッセージに対するデータ形式が一致する必要があり、バイト配列の問題を考慮しなければならない。相手側のアプリケーションのコンポーネント識別子を取得するために、アプリケーションはEM_LIST_APPSメッセージを送信することによって全ての実行中のアプリケーションのリストが送信されるように要求することができる。このメッセージは、現在実行中の全ての公開されているアプリケーションのリストを戻す。
【0267】
8.5 リーダメッセージ
本節では、各EM_READER_* メッセージを転送するためにイベントマネージャ301により使用される規則の概要を説明する。以下のメッセージは、どのアプリケーションが現在フォーカスをもっているかに関わらず、常にランチャ303に送信される。
・EM_READER_INSERT
・EM_READER_REMOVE
・EM_READER_BADCARD
・EM_READER_LOW-BATT
対応するフィールド1106中に現在のフロントアプリケーションと同じサービス識別子を有するカード10からのものである場合、以下のメッセージは現在のフロントアプリケーションに送信される。サービス固有識別子はこの比較では考慮されない。サービス識別子が現在のフロントアプリケーションと異なる場合、あるいは、区別用識別子がNO_CARDの現在値(すなわち、全て0)である場合、メッセージは前述のようにランチャ303に送信される。
・EM_READER_PRESS
・EM_READER_RELEASE
・EM_READER_MOVE
【0268】
8.6 メッセージ送信に対する規制
システム600の安全性及び安定性を改善するためには、メッセージの送信に対して規制が課されるのが好ましい。この規則に違反するメッセージはイベントマネージャ301により破棄されることになる。
【0269】
8.6.1 全てのコンポーネントに対する規制
リモートリーダ1以外のコンポーネントにはEM_READER_*メッセージを送信する許可が与えられない。
【0270】
8.6.2 イベントマネージャに対する規制
イベントマネージャ301は規則の実施者であり、そのように任意の必要なメッセージを送信することができる。イベントマネージャ301は、EM_KILL_LAUNCHERメッセージ及びEM_NEW_LAUNCHERメッセージのみを生成するだけで良いように構成されるが、メッセージをコピーし、そのコピーを目的のコンポーネントでないプロセスコンポーネントに送信することができる。また、イベントマネージャ301はコンポーネント間の全ての送信を扱う。
【0271】
8.6.3 ランチャに対する規制
ランチャ303は、アーキテクチャ200の全てのコンポーネント301から306にメッセージを送信する。ランチャ303が送信することができないメッセージは以下の通りである:
・EM_KILL_LAUNCHER
・EM_NEW_LAUNCHER
【0272】
8.6.4 アプリケーションに対する規制
アプリケーションが他のアプリケーション(ランチャ303を含む)に送信するのは以下のメッセージのみである:
・EM_APP_REGISTER
・EM_SEND_MESSAGE
・EM_LIST_APPS
・EM_POST_MESSAGE
・EM_GET_MESSAGE
・EM_DELETE_MESSAGE
・EM_LIST_MESSAGES
【0273】
8.7 コンポーネント手順リスト
本節では、アーキテクチャ200の各コンポーネントが関係する機能を列挙する。
【0274】
8.7.1 イベントマネージャ
イベントマネージャ301は以下の手順に直接関与する:
・システム初期化
・システム起動
・新規のアプリケーションの開始
・アプリケーションの終了
・フォーカス変更
・メッセージの受け渡し
・リーダメッセージ
【0275】
8.7.2 ランチャ
ランチャ303は以下の手順に関与する:
・システム初期化
・システム起動
・新規のアプリケーションの開始
・アプリケーションの終了
・フォーカス変更
・メッセージの受け渡し(場合による)
・リーダメッセージ(場合による)
【0276】
8.7.3 アプリケーション
アプリケーション304は以下の手順に関与する:
・新規のアプリケーションの開始
・アプリケーションの終了
・アプリケーションが永続的な場合のセッションの終了
・フォーカス変更
・メッセージの受け渡し
・リーダメッセージ(場合による)
【0277】
9.0 I/Oデーモン
I/Oデーモン300は、リモートリーダ1からイベントマネージャ301に送信され、双方向プロトコルの場合は逆方向にも送信されるデータを転送する役割を担う。I/Oデーモン300は、システム600のハードウェアから直接に、あるいは、IRリンク又は標準シリアルハードウェア接続などのリモートリーダ1とのインタフェースであるオペレーティングシステムドライバを介して読むことができるように構成される。また、I/Oデーモン300には、TCP/IPポートで聞き取りながらイベントマネージャ301が接続するのを待つことが要求される。ここで、I/Oデーモン300はTCP/IPストリーム中にカプセル化した状態でデータをリモートリーダ1からイベントマネージャ301に送信する。
【0278】
I/Oデーモン300は、リモートリーダ1のデータをイベントマネージャ301に送信する場合及びI/Oデーモン300とリモートリーダ1との間でのオプションの双方向プロトコル構成において逆方向の送信を行なう場合を除き、システム600のその他の部分とは通信を行なわない。
【0279】
I/Oデーモン300の機能はシステム600に存在しなければならないが、I/Oデーモン300は独立したコンポーネントである必要はない。例えば、イベントマネージャ301がリモートリーダ1とインタフェースをとるのに使用されるハードウェアと同じマシン上で実行されている場合、I/Oデーモン300はイベントマネージャ301へと統合することができる。
【0280】
I/Oデーモン300は、システム600のその他の部分がリモートで実行されている場合、最小限のハードウェア上で稼働するように構成される。
【0281】
9.1 要求事項
9.1.1 一般的な要求事項
I/Oデーモン300が実現されるプラットフォームは、リモートリーダ1から信号を受信(オプションとして、信号を送信)できるように構成されなければならない。また、プラットフォームは、システムのその他の部分(すなわち、イベントマネージャ(EM)301)と通信を行なうために、TCP/IPスタック又はその他の信頼性の高い通信方法を実現するのが好ましい。I/Oデーモン300は、多重化I/Oを行なうように要求される可能性があり、アーキテクチャ200のI/Oシステムは多重化I/Oをサポートするように構成されるのが好ましい。アーキテクチャ200は、I/Oデーモン300が聞き取りを行なうであろうポートを、例えば、コマンドライン引数として割り当てるように構成されるのが好ましい。
【0282】
9.1.2 内部の要求事項
I/Oデーモン300は、リモートリーダ1により使用されるプロトコルを理解する必要はない。I/Oデーモン300に要求されるのは、受信する全てのデータを任意の聞き取り中のEM(イベントマネージャ)に転送することのみである。I/Oデーモン300は、通信リンクのトランスポートプロトコルにより(すなわち、エラー訂正コード又はそれに類するものを介して)サポートされない限り、リモートリーダ1からの送信のエラーを訂正する必要がない。使用中のトランスポートプロトコルがエラー検出をサポートするが、エラー訂正はサポートしない場合、エラーチェックに合格しないデータをイベントマネージャ301に渡すことができる。
【0283】
9.1.3 外部インタフェースの要求事項
I/Oデーモン300は、1つ以上のTCP/IP接続を受け入れることができるのが好ましい。イベントマネージャ301に送信されるデータストリームは、リモートリーダ1により送信されるデータの内容である。使用される通信プロトコルの一部として送信される全てのヘッダ情報及びフッタ情報は除去されるのが好ましい。バイト配列はビッグエンディアンである。アーキテクチャ200の通信方法が使用不可能になる(例えば、エラー発生が原因)場合、I/Oデーモン300はエラー状態が起こると即座に全ての接続を終了する。
【0284】
9.2 外部インタフェース
I/Oデーモン300の外部インタフェース(不図示)は、最小限のハードウェア上で実行可能であるように意図的に簡単なものとなっている。I/Oデーモン300は以下のように構成されるのが好ましい。
【0285】
9.2.1 起動手順
I/Oデーモン300は、何らかの方法で、例えば、コマンドライン引数により指定されるTCP/IPポートで聞き取りを行なう。I/Oデーモン300にTCP/IPポートを通知する厳密な方法は実現例に依存する。リモートリーダ1と通信するために使用される通信ハードウェアは必要に応じて初期化され、リモートリーダ1から送信されるデータを読む方法はデータを受信できる状態にあるように構成される。接続を待つ間、I/Oデーモン300はリモートリーダ1により送信されるデータを消費するので、接続されたときには新規のデータのみが送信される。この新規のデータはメッセージ境界で開始する必要がない。
【0286】
9.2.2 イベントマネージャからの接続
TCP/IPポートで接続が成功する場合、I/Oデーモン300はその接続を受け入れ、接続を下ってリモートリーダ1から受信されるデータの送信を開始するように構成される。I/Oデーモン300が既にイベントマネージャ(EM)301に接続されている場合、I/Oデーモン300には2つの選択肢がある。まず、I/Oデーモンは接続を受け入れ、全ての現在接続されているイベントマネージャを下って全てのデータを送信することができる。この選択肢はシステムデバッギングのために提供される。第2の方法は第2の接続を拒否し、既に接続されているEMへのデータの送信を継続する方法である。ストリームの暗号化は、ポートトンネリングなどの他の何らかの方法によって外部で処理することができる。
【0287】
9.2.3 イベントマネージャからの接続の終了
いつでもイベントマネージャ301への接続が終了する場合には、I/Oデーモン300はイベントマネージャ301に送信されるのを待っているリモートリーダ1からのデータを破棄するように構成される。これが接続されている唯一のイベントマネージャである場合、I/Oデーモン300は初期の起動状態に戻るように構成される。これにより、I/Oデーモン300はリモートリーダ1により送信されるデータを消費しながら接続を待つ。
【0288】
9.2.4 回復不能エラーの出現
対処不可能であり、I/Oデーモン300の終了を引き起こすであろうエラーをI/Oデーモン300が検出する場合、I/Oデーモン300はEMへの全ての接続を終了し、EMにI/Oデーモン300がエラーを検出したことを通知するように構成される。エラーの例としては、リモートリーダ1と通信するのに使用されるハードウェアが使用不可能になる場合、あるいは、I/Oデーモン300が終了を引き起こすであろう信号を受信する場合が含まれる。I/Oデーモン300はエラーに遭遇すると即座に全ての接続を終了するように構成される。
【0289】
10.0 ランチャ
ランチャ303は、許可されたアプリケーション及び基本アプリケーションの構成規則などのサイト特有の規則を実施するプロセスコンポーネントである。ランチャ303は、システムアーキテクチャ200の他のコンポーネントプロセス300、301、304、305、及び306が、一般家庭のセットトップボックス601から非常に特殊なアプリケーション(例えば、現金自動預払機)に至る広範囲のアプリケーションにおいて使用されるのを許可する。ランチャ303は、ネットワークごと又は施設ごとに個別に作成することができる。
【0290】
ランチャ303は特権を有するように構成される。例えば、ランチャ303は、システム600が起動する際にイベントマネージャ301に接続する最初のコンポーネントになるように構成することができる。更に、ランチャ303は、リモートリーダ1により送信される全ての「LOW_BATT」メッセージ、「BADCARD」メッセージ、「INSERT」メッセージ、及び「REMOVE」メッセージを受信すると共に、任意の時点においてフロントアプリケーションが関連付けられるスマートカード10以外のカードから送信される全ての「PRESS」メッセージ、「RELEASE」メッセージ、及び「MOVE」メッセージを受信する。また、ランチャ303は特殊な「NO_CARD」区別用識別子を有するPRESSメッセージ、RELEASEメッセージ、及びMOVEメッセージも受信する。ランチャ303は、更に、EM_GAINING_FOCUSイベント及びEM_LOSING_FOCUSイベントを介してどのアプリケーションをフロントアプリケーションにするかに関する制御権を有する。
【0291】
ランチャ303は、アプリケーションがいつ開始され、いつ終了させられる必要があるかを決定するように構成される。また、ランチャ303は、常にそうである訳ではないが、アプリケーションを開始/終了するのに使用される。この役割は、例えば、アプリケーション304がアーキテクチャ200のその他のコンポーネントとは別のマシンで実行される場合に、ランチャ303の指示に応じて別のアプリケーションが引き受けることができる。
【0292】
イベントが現在のフロントアプリケーションではなく、ランチャ303に送信されることにより、ランチャ303はどのアプリケーションが任意の時点において実行されるべきかを決定することができる。アプリケーションを強制的に終了するように構成されることは、ランチャ303がどのアプリケーションが現在実行中であるべきかを強制できることを意味する。また、ランチャ303には、アプリケーションをいつ開始/終了するかをイベントマネージャ301に通知することも要求される。
【0293】
図36は、ランチャ303により実行される方法3700の概要を示すフローチャートである。方法3700は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。方法3700は第1のステップ3701で開始される。ステップ3701において、ランチャ303はイベントマネージャ301に接続し、次のステップ3702へと続く。ステップ3702において、永続的なアプリケーションが開始される。次のステップ3703において、ランチャ303はイベントを待ち、イベントが受信されるとステップ3705へと進む。ステップ3705において、イベントがNO_CARD識別子である場合、プロセスはステップ3707へと進む。NO_CARD識別子でない場合、プロセスはステップ3709へと進む。ステップ3707において、ランチャ303はNO_CARD識別子に応じて所定のシステム特有の機能(例えば、ディスプレイ101にメッセージを表示)を実行し、方法3700はステップ3703へと戻る。
【0294】
決定ステップ3705におけるイベントがNO_CARD識別子でないと判定されると、別の決定ステップ3709へと入り、イベントがPRESS、RELEASE、REMOVE、又はMOVEであるか否かが判定される。この決定ステップ3709が「yes」を戻す場合、すなわち、イベントが前述のイベントのうちの1つである場合、方法3700はステップ3800へと進む。イベントが前述のイベントのうちの1つでない場合、方法3700は更なる決定ステップ3713へと進む。ステップ3800において、ランチャ303はフローチャートの図37を参照して説明したプロセスステップに従ってアプリケーションを変更する。
【0295】
ステップ3709におけるイベントがPRESSイベント、RELEASEイベント、REMOVEイベント、及びMOVEイベントのうちの1つでない場合、決定ステップ3713に入る。この決定ステップ3713はBADCARDイベント又はLOW_BATTイベントに関する判定を行なう。ステップ3713において、イベントがBADCARDイベント又はLOW_BATTイベントである場合、方法3700はステップ3715へと進み、いずれのイベントでもない場合、方法3700はステップ3717へと進む。ステップ3715において、ランチャ303はユーザに対して発生したイベントに関するフィードバック(例えば、LOW_BATTイベントが判定される場合はディスプレイ101上に「バッテリ低下」メッセージを表示し、BADCARDイベントの判定の際には「不正なカード」を表示)を行ない、方法3700はステップ3703へと戻る。決定ステップ3713におけるイベントがBADCARDイベントでもLOW_BATTイベントでもない場合、ステップ3717に入る。
【0296】
ステップ3717において、イベントがAPP_REGISTERである場合、方法3700はステップ3900の「アプリケーション登録」へと進む。APP_REGISTERでない場合、方法3700はステップ3725へと進む。ステップ3900において、図38を参照してここで説明するように(すなわち、第8.3.4節を参照して先に説明したように、アプリケーションが他のコンポーネント301、302、及び306にメッセージの受信が可能な状態になったことを通知する)アプリケーションが登録され、方法3700はステップ3703へと戻る。ステップ3900に従ってアプリケーションを登録する方法については、図38のフローチャートを参照して詳細に後述する。ステップ3725においてイベントは破棄され、方法3700はステップ3703へと戻る。
【0297】
図37は、アプリケーションを変更する方法3800を示すフローチャートであり、この方法はランチャ303により実行される。方法3800は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。方法3800はステップ3817で開始される。ステップ3817において、ランチャ303によりREMOVEメッセージが受信されると、プロセスは直接ステップ3813へと進む。REMOVEメッセージが受信されない場合、方法3800は決定ステップ3801へと続く。決定ステップ3801において、イベントにより表されるサービスが登録されているアプリケーションと関連付けられている場合、方法3800は直接ステップ3819へと進む。アプリケーションと関連付けられていない場合、方法3800はステップ3803へと続く。ステップ3803において、新規のアプリケーションの位置及び/又は名前と新規のアプリケーションと関連付けられる初期データとを判定するために、サービス識別子参照が実行される。例えば、初期データはブラウザ403へとロードされるURLであっても、あるいは、メディアプレーヤアプリケーションへとロードされるメディアファイルであっても良い。次のステップ3805において、アプリケーションが既に実行中の場合、方法3800はステップ3819へと進む。アプリケーションが実行中でない場合、方法3800はステップ3809へと進む。ステップ3809において、新規のアプリケーションがアプリケーション304から得られる。次のステップ3811において、新規のアプリケーションがフロントアプリケーションとして開始される。ステップ3812において、イベントマネージャ301にはこの新規のフロントアプリケーションのコンポーネント識別子(Xid)が通知される。
【0298】
イベントにより表されるサービスが登録されているアプリケーションと関連付けられている場合(ステップ3801から)、あるいは、アプリケーションが既に実行中の場合、決定ステップ3819に入る。ステップ3819において、INSERTメッセージがランチャ303により受信されたと判定される場合、方法3800は終了する。判定されない場合、方法3800はステップ3807へと進む。ステップ3807において、新規のアプリケーションがすぐに変更状態になることを示すGAINING_FOCUSイベントが新規のアプリケーションに送信される。新規のアプリケーションにGAINING_FOCUSイベントが送信された後、あるいは、決定ステップ3817でREMOVEイベントが検知された結果、制御が決定ステップ3813に渡される。ステップ3813において、現在のフロントアプリケーションが存在するか否かが判定される。既にフロントアプリケーションが存在しない場合、方法3800は終了する。フロントアプリケーションが存在する場合、前のフロントアプリケーションにLOSING_FOCUSイベントが送信され、前のフロントアプリケーションは方法3800が終了する前に当座のタスクを終了することができる。
【0299】
図38は、新規のアプリケーションを登録する方法又はプロセス3900を示すフローチャートであり、この方法はランチャ303により実行される。方法3900は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。プロセス3900はステップ3901で開始される。ステップ3901において、アプリケーションを含み、図36のステップ3900を参照して言及される新規のサービスグループリストが生成される。次のステップ3903において、このアプリケーションにGAINING_FOCUSイベントが送信される。ステップ3905において、いずれのアプリケーションも新規のサービスグループの一部でなく、永続的でもない場合、方法3900はステップ3907へと進む。サービスグループの一部であるか、あるいは、永続的である場合、方法3900は終了する。ステップ3907において、サービスグループの一部でないアプリケーションにはEXIT_NOWイベントが送信され、方法3900は次のステップ3908へと進む。ステップ3908において、イベントマネージャ301は新規のサービスグループの一部でないアプリケーションが終了したことを通知される。その後、方法3900は終了する。
【0300】
図39は、ランチャ303からイベントを受信するときにアプリケーションにより実行されるプロセスステップ4000を示すフローチャートである。方法4000は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。方法4000はステップ4001で開始される。ステップ4001において、ランチャ303はイベントマネージャ301に接続し、方法4000はステップ4002へと進む。ステップ4002において、ランチャ303にAPP_REGISTERメッセージを送信することによってアプリケーションが登録される。図39に示すフローチャートを次のステップ4003までたどると、アプリケーションはイベントを待ち、イベントが受信されるとプロセスはステップ4005へと進む。ステップ4005において、イベントがGAINING_FOCUSイベントである場合、方法4000はステップ4007へと進む。GAINING_FOCUSイベントでない場合、方法4000はステップ4009へと進む。ステップ4007において、オプションとして区別用識別子を使用すると共にオプションとしてGAINING_FOCUSイベントのデータフィールドを使用することによって、必要に応じてアプリケーションが初期化される。初期化に使用されるこのデータフィールドは、ロード対象のURL、ロード対象のファイル名などを含んでも良い。制御はステップ4003におけるイベント待ちに戻る。
【0301】
ステップ4009において、イベントがPRESSイベント、RELEASEイベント、又はMOVEイベントである場合、方法4000はステップ4011へと進む。いずれのイベントでもない場合、方法4000はステップ4013へと進む。ステップ4011において、イベントに応じてアプリケーション特有の動作が実行される。アプリケーション特有の動作は、イベントからのデータ(すなわち、カード10上の印と関連付けられるデータ(例えば、URL、キャラクタ又はビデオの名前))、X/Y位置又は区別用識別子、あるいは、これらの任意の組み合わせを使用して実行される。
【0302】
アプリケーション特有の動作は、通常、カード10上の印と関連付けられる。例えば、印は特定のURLと関連付けることが可能であり、印が押下されるときにURLがアクセスされても良い。このため、例えば、コンピュータ100又はSTB601はURLにより指定されたウェブページから所望のプログラムをダウンロードすることができ、カードユーザはシステム600からサービス(すなわち、プログラムダウンロード)を受け取ることができる。更に、印は特定のメモリアドレスと関連付けることが可能であり、印が押下されるときにそのメモリアドレスにデータを格納するのにアドレスを使用することができる。従って、例えば、コンピュータ100又はSTB601はメモリアドレスにより指定されたメモリ又はネットワーク上のファイルサーバから所望の画像データをダウンロードすることができ、カード10のユーザはシステム600からサービス(例えば、画像データダウンロード)を受け取ることができる。ステップ4011の後、図39に示すように、方法4000はステップ4003へと戻る。
【0303】
上述の図39のフローチャートによると、対応する決定ステップ4005又は4009において、イベントがGAINING_FOCUSイベント、PRESSイベント、RELEASEイベント、及びMOVEイベントのうちのいずれかであると判定されない場合、プロセスステップ4000はフィルタを通過してステップ4103へと至る。ステップ4013において、イベントがLOSING_FOCUSイベントである場合、ステップ4013において、方法4000はステップ4015へと進む。LOSING_FOCUSイベントでない場合、方法4000は決定ステップ4017へと進む。ステップ4015において、アプリケーションは非アクティブ状態へと戻り、方法4000はステップ4003へと戻る。ステップ4017において、イベントがEXIT_NOWイベントである場合、方法4000は終了する。EXIT_NOWイベントでない場合、方法4000はステップ4019へと進む。ステップ4019において、イベントは無視され、方法4000はステップ4003へと戻る。
【0304】
図40は、ランチャ303からイベントを受信するときにブラウザコントローラ402アプリケーションにより実行される方法4100を示すフローチャートである。方法4100は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。方法4100はステップ4101で開始される。ステップ4101において、ブラウザアプリケーションはランチャ303にAPP_REGISTERメッセージを送信する。次のステップ4103において、ブラウザアプリケーションはイベントを待ち、イベントが受信されると方法4100はステップ4105へと進む。ステップ4105において、イベントがGAINING_FOCUSイベントである場合、方法4100はステップ4107へと進む。GAINING_FOCUSイベントでない場合、方法4100はステップ4109へと進む。ステップ4107において、アプリケーションは必要に応じて初期化される。例えば、アプリケーションはGAINING_FOCUSメッセージのデータフィールドを読み、データフィールドがURLを表す場合、そのURLをロードする。初期化は、初期URLをブラウザアプリケーション403へとロードし、URLのベースを格納することによってブラウザコントローラ402上で実行される。方法4100は次のステップ4121へと続く。ステップ4121において、区別用識別子がイベントから判定される。次のステップ4123において、現在のトップレベル文書中で引数としての区別用識別子1110と共にJavaScriptコールバック関数(Notify_Card_IDとして知られるのが好ましい)が呼び出され、方法4100はステップ4103へと戻る。
【0305】
ステップ4109において、イベントがPRESSイベント、RELEASEイベント、又はMOVEイベントである場合、方法4100はステップ4200へと進む。いずれのイベントでもない場合、方法4100はステップ4113へと進む。ステップ4200において、イベントに応じてブラウザアプリケーション特有の動作が実行される。ブラウザアプリケーション特有の動作については、図41のフローチャートを参照して詳細に後述する。ステップ4200の後、方法4100はステップ4103へと戻る。
【0306】
ステップ4113において、イベントがLOSING_FOCUSイベントである場合、方法4100はステップ4115へと進む。LOSING_FOCUSイベントでない場合、方法4100はステップ4117へと進む。ステップ4115において、ブラウザアプリケーションは非アクティブ状態へと戻り、方法4100はステップ4103へと戻る。
【0307】
ステップ4117において、イベントがEXIT_NOWイベントである場合、方法4100は終了する。EXIT_NOWイベントでない場合、方法4100はステップ4119へと進む。ステップ4119において、イベントは無視され、方法4100はステップ4103へと戻る。
【0308】
図41は、ソフトウェアアーキテクチャ200を組み込むシステム600上で実行されるブラウザアプリケーション方法4200を示すフローチャートである。方法4200は、コンピュータで実現する場合にはCPU205により実行することができる。また、セットトップボックスで実現する場合にはCPU4305により実行することができ、リモートサーバのCPUによっても実行することができる。方法4200はステップ4201で開始される。ステップ4201において、イベントがPRESSイベントである場合、方法4200はステップ4225へと進む。PRESSイベントでない場合、方法4200はステップ4203へと進む。ステップ4203において、イベントは無視され、方法4200は終了する。ステップ4225において、区別用識別子がイベントから判定される。次のステップ4227において、現在の区別用識別子について現在のページに通知されている場合、方法4200はステップ4205へと進む。通知されていない場合、方法4200はステップ4229へと進む。ステップ4229において、現在のトップレベル文書中で引数としての区別用識別子と共にNotify_Card_IDとして知られるJavaScriptコールバック関数が呼び出され、方法4200はステップ4205へと進む。
【0309】
ステップ4205において、データがイベントから得られる。次のステップ4207において、データが1文字である場合、方法4200はステップ4209へと進む。1文字でない場合、方法4200はステップ4211へと進む。ステップ4209において、文字がブラウザアプリケーション403に送信され、方法4200は終了する。これは、ユーザがキーボードのキー又は従来のリモコンのボタンを押下するのと同じ効果を提供するのに使用されても良い。現在のページは、Hyper Text Mark-up Language(HTML)により提供されるような既存の方法を使用して、任意のキー押下を受信する際に実行される動作を提供しても良い。
【0310】
ステップ4211において、データが「js:」で開始される場合、方法4200はステップ4213へと進む。「js:」で開始されない場合、方法4200はステップ4215へと進む。ステップ4213において、現在のトップレベル文書中のJavaScript関数が呼び出され、方法4200は終了する。指定のデータはオプションとしてJavaScript関数に対する引数を含んでも良い。例えば、データ「js:hello」はブラウザコントローラがJavaScript関数「hello」を呼び出すことを示し、データ「js:hello(world)」はブラウザコントローラが引数「world」と共にJavaScript関数「hello」を呼び出すことを示すことになる。
【0311】
ステップ4215において、データが「cmd:」で開始される場合、方法4200はステップ4217へと進む。「cmd:」で開始されない場合、方法4200はステップ4219へと進む。ステップ4217において、指定のブラウザ関数が呼び出され、方法4200は終了する。例えば、データ「print」により、ブラウザコントローラはデータ「back」がブラウザコントローラにより前に表示されたページに戻るようにブラウザに指示するように指示するであろう。
【0312】
ステップ4219において、データが絶対URLである場合、方法4200はステップ4221へと進む。絶対URLでない場合、方法4200はステップ4223へと進む。ステップ4221において、データがURLとしてブラウザアプリケーション403へとロードされ、方法4200は終了する。
【0313】
ステップ4223において、ベースURLが付加された後、データはURLとしてブラウザアプリケーション403へとロードされ、方法4200は終了する。
【0314】
図40を参照して先に説明したブラウザコントローラアプリケーションの変形例がソフトウェアプログラムを制御するプログラムコントローラである。ソフトウェアプログラムは、1つ以上のキー押下イベント(例えば、キーボードのキー押下イベント又はゲームコントローラでのそれに類するイベント)と共に通常制御される任意のプログラムを含むことができる。プログラムコントローラは、対話式ゲームなどの既存のソフトウェアプログラムのカードベースの制御を提供するのに使用することができる。プログラムコントローラプロセスは、以下に示すような例外はあるが、図40を参照して説明したのとほぼ同様に動作する。ステップ4105におけるイベントがGAINING_FOCUSイベントである場合、プログラムコントローラプロセスはGAINING_FOCUSメッセージから制御対象のソフトウェアプログラムに対するリソースロケータを取得するステップへと進む。プロセスは、リソースロケータにより指定されるソフトウェアプログラムを取得・開始するステップへと進む。プログラムコントローラプロセスはステップ4103へと進む。更に、ステップ4109において、PRESSイベント、RELEASEイベント、又はMOVEイベントを検査する代わりに、方法4100におけるこの変形例は実質的にPRESSイベントについてチェックするであろう。イベントがPRESSイベントである場合、プロセスはイベントからデータを取得し、データから最初の文字をとり、その文字のキー押下を実現し、結果的に、ユーザがキーボード上でその文字をタイプしたのと同じ効果が得られるステップへと進む。
【0315】
10.1 ランチャに対する特殊なルーティング規則
ランチャ303は特殊な一連のルーティング規則を有し、以下のイベントを常時受信する:
・EM_REMOTE_INSERT
・EM_REMOTE_REMOVE
・EM_REMOTE_BADCARD
また、ランチャは、サービス識別子が現在のフロントアプリケーションと一致しない場合、あるいは、区別用識別子がNO_CARDの現在の識別子(すなわち、全て0)を表す場合、EM_REMOTE_PRESSメッセージ、EM_REMOTE_ RELEASEメッセージ、及びEM_REMOTE_MOVEメッセージを受信する。メッセージが一致するか否かを判定するために、サービス固有識別子は無視される。
【0316】
ランチャ303は、EM_GAINING_FOCUSイベントをそれ自体に送信することによって明確にそれ自体をフロントアプリケーションにするように構成することができる。この例では、全てのメッセージはメッセージのサービス識別子に関わらずランチャ303に送信されることになる。ランチャ303は、プロトコルによってこれらのメッセージのいずれかに応答する必要はない。
【0317】
10.2 サンプル実現例
本節はランチャ構成の幾つかの例の概要を説明する。
【0318】
10.2.1 総称ランチャ
総称ランチャは、ブロードバンドインターネット接続能力を有するオープンなセットトップボックス又はコンピュータ環境で使用することができる。この構成によると、ランチャ303はローカルマシン又は指定のリモートマシンへとダウンロードし、実行させることができるアプリケーションが存在することを前提とする。また、総称ランチャは、ブラウザコントローラ402を介してブラウザ403を使用するアプリケーションを使用できるように構成することができる。
【0319】
総称ランチャは、永続的なアプリケーションをサポートすると共に、アプリケーションをダウンロードするように構成することができる。システム600を稼働させるコンピュータ100は、相当に高速なインターネット接続が利用可能であるのが好ましい。この例では、アプリケーション304の一部は、上述のように、ブラウザコントローラ402と呼ばれる永続的なアプリケーションにより処理されるJavaScriptを有するウェブページであっても良い。更に、アプリケーション304の一部は協働するように設計することができる。また、総称ランチャは、リモートリーダ1により使用される通信リンクの信頼性が低く(すなわち、IRリンク)、メッセージが損失する可能性があることを前提とするのが好ましい。
【0320】
10.2.2 総称ランチャに対する規則
以下の規則は、ランチャ303がシステム600を定義するのに使用されるのが好ましい規則である。
【0321】
・NO_CARDの現在の識別子(すなわち、全て0)を有するEM_REMOTE_PRESSイベント及びEM_REMOTE_RELEASEイベントは、ユーザがフロントアプリケーションから出ることを希望する合図として使用される。システム600はその構成により、ディスプレイ101上に「カードを挿入してください」メッセージを生成するか、あるいは、前のアプリケーションへと戻ることになるであろう。
【0322】
・EM_REMOTE_BADCARDイベントにより、ランチャ303はカードが不良であることを示すフィードバックをユーザに提供する。
【0323】
・リモートリーダ1からイベントマネージャ301までの通信方法の信頼性が低いことが前提とされているため、EM_REMOTE_INSERTイベント及びEM_REMOTE_REMOVEイベントは、セッションの境界を提供することが期待されていない。
【0324】
・EM_REMOTE_PRESSメッセージ、EM_REMOTE_RELEASEメッセージ、又はEM_REMOTE_MOVEメッセージを受信する場合、ランチャ303はサービスマッピングを行ない、サービス識別子がダウンロード可能なアプリケーションへと分解される場合、対応するアプリケーションがダウンロードされ、実行される。マッピングは、カードからのサービス情報を伴ってディレクトリサーバ305に問合せを行なうことによって実行される。ディレクトリサーバ305から戻される値は、アプリケーション位置及び関連するサービスデータである。アプリケーション位置は、アプリケーションの位置又はローカルアプリケーションとしてランチャが認識する値を指定する。サービスデータは、EM_GAINING_FOCUSメッセージに含まれてアプリケーションに送信される初期化データである。アプリケーション位置が空の場合、ランチャ303はURLとなるであろうサービスデータに基づいてどのアプリケーションを使用すべきかを決定するように構成される。
【0325】
・新規のアプリケーションがEM_APP_REGISTERメッセージと共に登録されるとき、指定のサービスグループが現在実行中の一連のアプリケーションと比較され、重複がない場合、現在実行中の他の全てのアプリケーションは終了するように通知される。新規のアプリケーションは現在のフロントアプリケーションになり(EM_GAINING_FOCUSイベントを使用)、前のフロントアプリケーションにはEM_LOSING_FOCUSイベントが送信される。この状況が発生し、サービス識別子がウェブページへと分解される場合、EM_GAINING_FOCUSメッセージを使用することによって、データフィールドにウェブページのアドレス(位置)が入った状態でフォーカスがブラウザコントローラ402へと変更される。データフィールドは、ランチャ303にサービス識別子がウェブページへと分解されたことを通知する問合せに含まれて戻される。この状況で、EM_LOSING_FOCUSイベントも現在のフロントアプリケーションに送信される。他の全てのアプリケーションは終了するように通知される。
【0326】
10.3 単独使用のシステムの例
アーキテクチャ200は単一の専用アプリケーションと共に使用するように構成することができる。この例では、ユーザインタフェースの一部又は全体を印刷可能な物理的なトークン(例えば、バンクカード)を有するのが有利な場合にランチャ303を使用することができる。後述する例は自動現金預払機の形態をとるが、特殊なアプリケーションとして説明されているに過ぎず、自動現金預払機に限定されるものとして解釈すべきではない。このようなシステムは、1枚又は少なくとも非常に限定された枚数のカードを使用できるように構成することができる。このシステムでは、挿入されるカードに関わらず、他のアプリケーション304は開始されない。ランチャ303はシステムコントローラの役割に加え、単一のアプリケーション304の役割を担う。イベントマネージャ301には変更が加えられない。
【0327】
単独使用のシステムは、例えば、自動現金預払機に使用することができる。銀行は、表面に一般に用いられるオプションをつけた個人用バンクカードを作製することができる。このカードは、自動現金預払機に対する唯一又は補助のインタフェースとして使用される。この例では、自動現金預払機はイベントマネージャ301及びアーキテクチャ200の他のコアプロセスコンポーネントを含むのが好ましい。この例では、リモートリーダ1とイベントマネージャ301との間の通信リンクは信頼性の高いものでなければならない。
【0328】
10.3.1 規則
以下の規則は、ランチャ303が単独使用のシステムの銀行の現金自動預払機の一例を定義するのに使用することができる:
・参加銀行と関連付けられるカードによるものでないイベントは、ランチャが端末に互換性のないカードの画面を表示する原因となる。
・EM_REMOTE_BADCARDイベントは無視される。
・EM_REMOTE_INSERTイベントはトランザクションを開始するのに使用される。
・EM_REMOTE_REMOVEイベントはトランザクションを終了するのに使用される。
・EM_REMOTE_PRESSイベント、EM_REMOTE_RELEASEイベント、及びEM_REMOTE_MOVEイベントはユーザインタラクションとして扱われる。これらのイベントは実行中のアプリケーションのようにランチャにより直接処理されるのが好ましい。
・外部のディレクトリサーバへのサービスマッピングが行なわれることはない。カードが特定の自動現金預払機(ATM)が認識するものでない場合、カードは拒否される。
【0329】
これらの規則は、ATMの形態で専用のアプリケーションを提供するように単独使用のシステムを構成することができる方法の例である。
【0330】
10.4 ディレクトリサービスの動作
図58は、ディレクトリサービス311により実行されるプロセス5800の概要を示すフローチャートである。プロセス5800はコンピュータ100のCPU205により実行される。このCPU205がディレクトリサービス311の役割を果たす。図58に示すソフトウェアプログラムは、システム600Aのメモリ206又はCD−ROM212あるいはシステム600Bのメモリ4306などのメモリ媒体に格納される。プロセス5800は第1のステップ5801で開始される。ステップ5801において、ディレクトリサービス311が開始される。次のステップ5802において、CPUはランチャ303からの入力イベントを待つ。イベントはイベントマネージャ301を介して読取り装置1からランチャ303に送信される。次のステップ5803において、CPUはランチャ303から区別用識別子を含む要求を受信する。この区別用識別子はディレクトリサービス311によりマップされる。ランチャ303とディレクトリサービス311との間の接続は図8に示される。
【0331】
次のステップ5804において、CPUはディレクトリマッピングテーブルを検索し、テーブルが区別用識別子に対応するエントリを有するか否かをチェックする。ディレクトリマッピングテーブルは、通常、サービス識別子と対応するアプリケーション位置(URLなど)及びサービスデータとの間の関係を含み、更に、区別用識別子と対応するアプリケーション位置及びサービスデータとの間の関係を含む。通常、サービス識別子を含む関係はカード10に対して使用され、ディレクトリサービス311は、そのサービスに対して使用することができる全てのカード10に対するサービスレベル情報(例えば、カード10に対するサービスを提供するように実行されるアプリケーション304の位置)を維持することを目的とする。また、区別用識別子を含む関係はカード10に対して使用され、ディレクトリサービス311は、同一のサービス固有識別子を有する実際のカード10又はカードのグループ10に特有の情報(例えば、カード10に対するサービスを提供するべく再生されるメディアファイルの位置)を維持することを目的とする。ディレクトリマッピングテーブルは、通常、ハードディスク210又はメモリ206に格納される。ステップ5804において、ディレクトリマッピングテーブル中に区別用識別子に対するエントリがある場合、次のステップ5805において、CPUはこのエントリからアプリケーション位置及びサービスデータを取得し、ステップ5806へと移る。ステップ5804において、テーブル中に区別用識別子に対するエントリが存在しない場合、ステップ5808において、CPUはこの値の関連部分(通常は、図11に示すような最初の5バイト)をとることによって区別用識別子からサービス識別子を抽出する。次のステップ5809において、CPUはサービス識別子に対応するエントリを求めてディレクトリマッピングテーブルを検索する。エントリが見つかった場合、次のステップ5810において、CPUはこのエントリからアプリケーション位置及びサービスデータを取得し、ステップ5806へと移る。ステップ5811において、エントリが見つからない場合、特定の区別用識別子に対する要求が行なわれたことを示すエントリがログファイルに配置される。ステップ5812において、供給された区別用識別子のサービス識別子部分がディレクトリサービス311にとって未知のものであることを示すエラーがランチャ303に戻される。フローはステップ5802へと続く。
【0332】
ステップ5806において、すなわち、区別用識別子又はサービス識別子の検索が成功した場合、区別用識別子と対応するアプリケーション位置及びサービスデータとがログファイルに書き込まれ、CPUは要求を行なったランチャ303にアプリケーション位置及びサービスデータを戻す。フローはステップ5802へと続き、別のイベントを待つ。
【0333】
11 総則
通常、アプリケーション304はハードディスクドライブ210に常駐し、CPU205による実行時に読み出され制御される。プログラム及びネットワーク220から取り込んだデータの中間記憶装置は、半導体メモリ206を使用し、場合によってはハードディスクドライブ210と協働させるように使用して達成されても良い。アプリケーション304は、CD−ROM又はフロッピーディスク上に符号化された形でユーザに供給され、対応するドライブ212又は211を介して読み取られる場合もあれば、ネットワーク220からモデム装置216を介して読み取られる場合もある。その他のコンピュータ可読な媒体からコンピュータシステム100へとソフトウェアアプリケーションをロードするその他のメカニズムには、磁気テープ、ROM又は集積回路、光磁気ディスク、コンピュータモジュール102と別の装置との間の無線又は赤外線の伝送チャネル、スマートカード、コンピュータのPCMCIAカードなどのコンピュータ可読なカード、及び電子メール送受信並びにウェブサイトなどに記録された情報を含むインターネット並びにイントラネットが含まれる。以上の媒体は、関連するコンピュータ可読な媒体のほんの一例である。上述の例の組み合わせを含め、その他のコンピュータ可読な媒体も使用可能である。
【0334】
また、上述のプロセスコンポーネント301から306は、上述の関数及び下位関数を実行する1つ以上の集積回路などの専用のハードウェアで実現することもできる。このような専用のハードウェアは、グラフィックCPU、デジタル信号CPU、又は、1つ以上のマイクロCPU及び関連メモリを含んでも良い。専用ハードウェアの例は、図6(b)を参照して説明したテレビ用のセットトップボックス601である。
【0335】
12 その他の変形例
12.1 セッション識別子
上述のように、区別用識別子は、リーダ1からコンピュータ100又はセットトップボックス601に送信される全てのINSERTメッセージ、REMOVEメッセージ、PRESSメッセージ、RELEASEメッセージ、及びMOVEメッセージに含まれる。また、区別用識別子はINSERTメッセージのみと共に送信することもできる。この例では、新規のカード10の挿入時に、リーダ1がセッション識別子(不図示)を生成する。セッション識別子はカード挿入の現在のセッションを識別する。セッション識別子は、例えば、擬似乱数(2バイトのデータを用いて表すことができる)とすることも、カードが挿入されるたびに増分される(所定の値に達すると0にリセット)数値とすることもできる。リーダ1はコンピュータ100又はセットトップボックス601にINSERTメッセージを送信する。このメッセージは先に説明した区別用識別子及び新規の挿入ごとに生成されるセッション識別子を含む。後続するPRESSメッセージ、RELEASEメッセージ、及びMOVEメッセージは、全て区別用識別子を含む必要がないが、セッション識別子と先に説明したユーザインタフェースオブジェクトデータ又は押下座標とを含むであろう。
【0336】
セッション識別子を使用するとき、システム600は、リーダ1からINSERTメッセージを受信する際にイベントマネージャ301がセッション識別子を現在のセッション識別子として格納し、区別用識別子を現在の区別用識別子として格納することを除いては図6(a)及び図6(b)を参照して説明したのと同様の処理を実行する。PRESSメッセージ、RELEASEメッセージ、又はMOVEメッセージを受信するとき、イベントマネージャ301はセッション識別子が現在のセッション識別子と等しいことを確認する。等しい場合、イベントマネージャ301は、全てのメッセージにおいて使用される区別用識別子を現在の区別用識別子に設定する。これに対し、セッション識別子が現在のセッション識別子と等しくない場合、イベントマネージャ301は、ディスプレイマネージャ306及び表示装置101を介してメッセージが対応するINSERTメッセージを伴わずに受信されたことをユーザに通知する。この場合ユーザは、例えば、カード10を抜き取って再挿入するように要求される。
【0337】
12.2 ユーザ押下のその他の特徴
上述のように、情報の送信は、リーダ1のタッチパネル8上でのオブジェクトの押下、移動、及び押下解除(通常、指又はスタイラスを用いる)に関する。しかし、リーダ1は、タッチパネル8からのインタラクションに関する追加の情報をシステム600により使用するためにコンピュータ100又はセットトップボックス601に送信することができる。例えば、追加の情報は、押下の結果タッチパネル8に対して作用する圧力の時間及び量を表すことができる。この追加の情報は、リーダ1からシステム600に送信されるPRESSメッセージに組み込むことも、システム600内で送信されるEM_READER_PRESSメッセージに組み込むこともできる。この例では、情報はリーダ1に挿入されるカードに対応するアプリケーション304に渡される。アプリケーションは、追加の情報を利用して、例えば、特定の動作に対して付加的な効果をもたらすことができる。例えば、アプリケーションは音量の増加を示す印の押下と関連付けられるときに、圧力情報を使用して音量の増加量を判定することができる。すなわち、選択された印に対する押下が強いと音量の増加率が高くなり、逆に、選択された印に対する押下が弱いと増加率が低くなる。
【0338】
タッチパネル8とのインタラクションの時間(すなわち、持続時間)に関し、追加の情報の使用の別の例を以下で説明する。押下の持続時間が非常に短い場合、押下は「タップ」であると見なすことができる。これに対し、押下の持続時間が非常に長い場合、キー押下の永続的な「押し下げ」であると見なすことができる。この例では、追加の情報はインスタントソフトウェアアプリケーションと対話するモードに追加の次元を加えることができる。例えば、タッチパネル8上での「タップ」をソフトウェアアプリケーションに現在の(画面上の)カーソル位置に表示される項目を選択するように指示する命令とすることができる。
【0339】
12.3 座標なし
PRESSメッセージ及びRELEASEメッセージは、ユーザのタッチパネル8とのインタラクションの座標データを含まないように構成することができる。この例では、座標データのみが、MOVEメッセージと共にリーダ1からシステム600に送信される。PRESSメッセージ及びRELEASEメッセージに座標データを含まないことの利点は、アプリケーション304が座標からユーザインタフェース要素データへとマッピングするのに座標情報を必要としない場合に、リーダ1によりシステム600に送信されるメッセージのサイズを縮小できることである。
【0340】
12.4 双方向プロトコル
単方向又は双方向通信は、リーダ1とコンピュータ100又はセットトップボックス601との間の通信に使用することができる。図10を参照したリーダ1の説明及び図8及び図9を参照したI/Oデーモンの説明は、リーダ1からコンピュータ100又はセットトップボックス601への情報の送信及び逆方向の送信を含むものであった。コンピュータ100又はセットトップボックス601からリーダ1への情報の送信は、カード10に格納されたデータを変更するのに使用することができる。例えば、スマートカード10のメモリチップ上に格納されたユーザインタフェースオブジェクトデータの変更に使用することができる。
【0341】
また、双方プロトコルはプロトコルにおけるハンドシェーキングを可能にするために使用することができる。例えば、リーダ1とセットトップボックス601又はコンピュータ100との間の双方向プロトコルは、カードがリーダ1に挿入されるときにシステム600がINSERTメッセージの受信を確認することができるように使用することができる。双方向プロトコルをサポートするシステム600は、アプリケーションがカード10上の格納されたデータの一部を変更するために要求を送信することができるように、イベントマネージャ301を介してI/Oデーモン300に送信されるイベントマネージャプロトコルでの追加のメッセージを提供すべきである。I/Oデーモン300は、リーダ1にメッセージを送信して要求される動作を引き起こすことができる。例えば、システム600が双方向プロトコルを使用する場合、システム600はアプリケーションがユーザの許可又はシステム定義の特権なしにカードを変更することができないことを保証するための機密保護メカニズムを提供することができる。このようなシステムの一例において、イベントマネージャ301は、アプリケーションが現在挿入されているカードを変更しても良いか否かを尋ねる表示メッセージをユーザに対して提示することができる。ユーザは、タッチパネル8の第1の領域を押下することによって提案に同意することができると共に、タッチパネル8の第2の領域を押下することによって提案への不同意を示すことができる。ユーザがカード10の変更に同意する場合、イベントマネージャ301は、アプリケーション304からの要求がI/Oデーモン300へと渡され、更に、リーダ1へと渡されるようにすることができる。これに対し、ユーザが変更に不同意の場合、イベントマネージャ301はメッセージを放棄するので情報はリーダ1に送信されない。
【0342】
12.5 代替の読取り装置
上述のシステム600A及び600Bにおいて、読取り装置1はカード10に重なるように構成されるほぼ透明な感圧膜を有する。読取り装置1の費用を削減するために、読取り装置1は感圧膜の代わりに複数のユーザ操作可能なスイッチをレセプタクルの周囲に配置しても良い。レセプタクルには、データ、すなわち、区別用識別子とデータを各スイッチと関連付けるための関係情報とを読むためにスマートカード10を挿入することが可能である。各スイッチのうちの操作可能なものはスマートカード上の印と視覚的と関連付けられるため、ユーザはカード上の少なくとも1つの印に対応するスイッチのうちの少なくとも1つを選択することができる。この場合、CPU45はカード10からの関係情報及び区別用識別子に基づいてユーザにより押下されるスイッチに対応するデータを読み、それをイベントマネージャ301に送信する。
【0343】
13.0 代替のソフトウェアアーキテクチャ
システム600により表されるハードウェアアーキテクチャに対する更なる一般的なソフトウェアアーキテクチャ4900が図48に示される。このアーキテクチャ4900は、これまで各節で説明したものの代替のソフトウェアアーキテクチャを表す。代替のアーキテクチャ4900は、ユーザの自宅における非常に低レベルのハードウェア要件(すなわち、簡易セットトップボックス)から、例えば、セットトップボックス601の機能がパーソナルコンピューティングシステム上で実現される強力なホームシステムに至るまでスケール変更されるように構成される。更に、代替の構成4900は、ハードウェアシステム600内で実現されるのが好ましい。
【0344】
13.1 構造
アーキテクチャ4900は、6つの別個のプロセス及び1つのプロセスクラスへと分割される。別個のプロセスは、アーキテクチャ200と同様にI/Oデーモンと呼ばれるスマートカードインタフェース4902、イベントマネージャ4904、ディスプレイマネージャ4906、マスタランチャ4908、(アプリケーション)ランチャ4910、及びディレクトリサービス4912を含む。プロセスクラスは1つ以上のスマートカードアプリケーション4920により形成される。アーキテクチャ4900には、セットトップボックス601により通常形成されるスマートカードリモート接続ごとに、1つのカードデーモン4902、1つのイベントマネージャ4904、1つのディスプレイマネージャ4906、及び1つのランチャ4910と、各ランチャ4910を稼動させているコンピュータごとに1つのマスタランチャ4908と、全てのシステムに対して少なくとも1つのディレクトリサービス4912とが存在する。
【0345】
この形態において、図48の破線により示すように、アーキテクチャ4900は3つの別個の部分4914、4915、及び4916へと物理的に分離することができる。各部分は物理的に別々の計算装置上で実行させることができる。システムの各部分間の通信は、アーキテクチャ200と同様にTCP/IPストリームを使用して実行される。
【0346】
I/Oデーモン4902は、スマートカードリモートリーダ1から受信されるデータグラムをTCP/IPストリームへと変換するプロセスである。I/Oデーモン4902は、リーダ1により使用されるデータ形式を理解するのではなく、スマートカードリモートデータ形式の変更とは関係なく動作することを意図し、複数のバージョンのリーダ1と協働する機能を提供する。
【0347】
I/Oデーモン4902は、ユーザがシステム600を開始するときに開始されるが、これは、セットトップボックスシステム600Bの場合、セットトップボックス601の電源が投入されるときである。コンピュータシステム600Aの場合、I/Oデーモン4902は、イベントマネージャ4904及びマスタランチャ4908が開始された後、ユーザがスマートカードシステムを開始するときに開始されても良い。
【0348】
イベントマネージャ4904は、全ての通信がイベントマネージャ4904を経由するという点でアーキテクチャ4900の中心を形成する。イベントマネージャ4904は、スマートカードリモートリーダ1により生成され、I/Oデーモン4902により中継される全てのイベントを収集する役割を担う。これらのイベントは、種々のプロセス及び実行中の各アプリケーションへと再分散される。
【0349】
イベントマネージャ4904の更なる役割は、挙動の悪いアプリケーションを他の挙動の良いアプリケーションから切り離すことである。この点に関して、イベントマネージャ4904を経由するイベントは、イベントマネージャ4904がチェック可能な範囲で正しいことが保証される。イベントマネージャ4904は、イベントが有効なヘッダ及び正しいデータ長を有することをチェックすることが要求されるが、通常、データが正しい形式であることをチェックするようには構成されていない。
【0350】
異なるバージョン間でのプロトコルの変更にも、イベントマネージャ4904が対処する。可能な場合には、動作中のアプリケーション4920が理解するデータ形式に適合するようにイベントは書き換えられる。書き換えが可能でない場合、イベントマネージャ4904は送信元のアプリケーション4920にエラーを報告する。異なるデータ形式バージョンが使用されている場合、イベントマネージャ4904は混乱の発生を最小限に抑えることを保証する。
【0351】
ディスプレイマネージャ4906は、どの動作中のアプリケーション4920が特定の出力装置116、典型的にはディスプレイ(例えば、116)に対して優先権を有するかに関して制御するように動作するアプリケーション4920と協働して動作する。どのビデオストリームがイベントマネージャ4904を介してディスプレイ116に送信されるかを選択するのがディスプレイマネージャ4906の役割である。この情報はアプリケーション4920の各ランチャ4910から得られる。一般的に、フロント(すなわち、フォアグラウンド)アプリケーションのみがビデオディスプレイストリームを生成する。更に、ディスプレイマネージャ4906は、整合性のない入力ストリームから一定のストリームを出力するように維持し、推定データを用いて出力ストリームの一部を補充するように動作しても良い。
【0352】
イベントマネージャ4904は、いつアプリケーション4920を開始/終了しなければならないかを決定する、あるいは、実際にアプリケーション4920を開始/終了する責任はない。後述するように、これらの動作はランチャ4908及び4910の責任である。更に、イベントマネージャ4904は、ユーザ画面又はその他の出力装置116にはその存在を示さない。スマートカードの最初の挿入の表示などのシステム関連のフィードバックはランチャ4910により実行される。
【0353】
代替のアーキテクチャ4900を組み込む図6(b)のシステム600Bの場合、通常、システム600Bに接続することを許された全てのセットトップボックス601に対してイベントマネージャ4904が実行されるであろう。アーキテクチャ4900を組み込むシステム600Aの場合、マスタランチャ4908が開始された後にスマートカードシステム600Aが開始されるときにイベントマネージャ4904が開始されることになる。
【0354】
マスタランチャ4908の役割は、イベントマネージャ4904のいずれかの要求に応じてランチャ4910を開始することである。I/Oデーモン4902がイベントマネージャ4904に接続するとき、イベントマネージャ4904はマスタランチャ4908にイベントマネージャ4904に対する第1のプロセスを開始するように要求する。この第1のプロセスは、通常、任意のスマートカードアプリケーション4920に対するランチャ4910であろう。また、マスタランチャ4908は、イベントマネージャ4904の要求時にアプリケーション4920のランチャ4910を停止すると共に、イベントマネージャ4904に正しいランチャ4910が終了したことを通知する役割を担う。
【0355】
代替のアーキテクチャ4900を組み込む図6(b)のシステム600Bの場合、スマートカードアプリケーション4920を実行する物理的に別々のサーバ150、152の各々に対して、常に、1つのマスタランチャ4908が実行されることになる。この1つのマスタランチャ4908は、そのサーバ上にランチャ4910を要求する全てのイベントマネージャ4904に対する要求に対処する。システム600Aの場合、マスタランチャ4908はスマートカードシステムのその他の部分より前又はそれと同時に動作を開始する。
【0356】
カードディレクトリサービス4912は、スマートカード10内に格納されるベンダ−アプリケーション値(サービス識別子の値)を後述するベンダ−アプリケーション対(サービス識別子)と関連付けられるアプリケーション4920を指し示すUniform Resource Locator(URL)などのアプリケーション位置へと変換するために設けられる。ディレクトリサービス4912は、アプリケーション4920がランチャ4910に対して別々のシステム上で実行可能であるようにランチャ4910を変更することによって複数の部分へと分割することができる。ディレクトリサービス4912は、分散型参照システムを使用してこの機能を実行する。このシステムでは、現在問合せを所持するディレクトリサービスがその答えを知らない場合、問合せは別のディレクトリサーバへと渡される。このような分散型システムにより、各ディレクトリサーバはベンダ−アプリケーションID対からURLへの変換について限られた知識を有することになるが、依然として全てのIDをURLへと変換することができる。これにより、各ディレクトリにおけるデータベースの簡易化を含め、数多くの利点が提供される。頑強性が向上し、サーバは問合せが許可されている間、動作不能になる(すなわち、クラッシュ又はサービスから外される)ことを許される。
【0357】
図52を参照すると、スマートカード10を従来のスマートカードと区別する制御テンプレートカスタマイズ情報は、ベンダ識別子、カード識別子、及びアプリケーション識別子によるデータの組を含む。ベンダ識別子/アプリケーション識別子対は、アーキテクチャ200に関して先に説明したサービス識別子に相当する。また、カード識別子は、アーキテクチャ200に関して先に説明したサービス固有識別子に相当する。更に、各アイコン4804と関連付けられるのは、ユーザがアイコン4804上のタッチパネルを押下するときにイベントデータとして送信される対応データである。このイベントデータは、特定のアプリケーション4920に渡されるとそのアプリケーション内の特定の動作を実施する。また、例えば、アイコンの押下ではなくアイコンの押下解除を検知するため、更に、ユーザがタッチパネル8を横断するように指をスクライブして特定の機能を実行する場合に押下の移動を検知するため、ユーザ動作の検知が組み込まれても良い。このような動作のたびに、カード上に格納されるイベントデータを送信することができる。このデータはその都度カード上のメモリの異なる位置から読まれても良い。この代替のアーキテクチャ4900においてベンダ−アプリケーション識別子対として実現されるサービス識別子により、スマートカードと関連付けられるアプリケーションのベンダは相互に区別することができる。スマートカードと関連付けられるアプリケーションのベンダを区別する必要がない場合のアーキテクチャ4900の展開において、ベンダ識別子及びアプリケーション識別子は、単一の値:サービス識別子として扱うことができる。
【0358】
スマートカード10のリーダ1への挿入により開始される第1のプロセスは、汎用システム(一般家庭など)ではランチャ4910になるであろう。特殊なシステムでは、特殊なアプリケーションが開始されても良い。例えば、バンキングテラーはバンキングアプリケーションを開始するであろう。別の例としては、アプリケーションの特定の部分集合のみを開始する限定的なランチャの使用が含まれる。ランチャ4910は、特定の1つのイベントマネージャ4904に対して他のアプリケーション4920を開始するスマートカードアプリケーションである。アプリケーション4920を開始/終了させ、実際にアプリケーションを開始/終了するのはランチャ4910の決定である。ランチャ4910は、イベントマネージャ4904にいつアプリケーションが開始/終了するかを通知し、アプリケーション4920にいつフォーカスを受け取る/失うか、あるいは、いつ終了する必要があるかを通知する。この点に関して、複数のアプリケーション4920が同時に動作している場合、現在画面に表示されているアプリケーションがフォーカスを有するアプリケーションである。別のアプリケーションが優先権を得ようとすると、ランチャ4910は現在のアプリケーションにフォーカスが失われることを通知するので、現在のアプリケーションは当座のタスクを完了することができる。また、ランチャ4910は新規のアプリケーションにフォーカスが得られ、まもなく新規のアプリケーションが変更状態に入ることを通知する。ランチャ4910はアプリケーションを強制的に終了できるように構成されなければならない。
【0359】
開始される第1のアプリケーション4920(すなわち、通常は、ランチャ4910)には特権が与えられ、リモートリーダ1により生成された「NO_CARD」イベント、「Bad_CARD」イベント、及び「POWER_OFF」イベントを受信する。また、第1のアプリケーション4920は、現在のフロントアプリケーションでない各アプリケーション4920用のイベントも受信し、これらのイベントを正確に解釈するように動作する。これは上述の特定のアプリケーションに関連するので、ランチャはあらゆる変化を正確に解釈する。ランチャ4910は、その他のアプリケーションを開始・停止する権利を含む特殊な権利を有するアプリケーション4920である。
【0360】
ランチャ4910は、イベントマネージャ4904によりその開始が要求されるときにのみ開始されるのが好ましい。また、ランチャ4910は、イベントマネージャ4904により終了するように指示することもできる。
【0361】
アプリケーションは、対応するスマートカード10上での第1のユーザ選択に対する応答として、あるいは、アプリケーション4920の別の1つの要求に応じてランチャ4910により開始される。この点に関して、アーキテクチャ4900は、プログラミング中に1つ以上のアプリケーションサービスグループのメンバとして編成される各アプリケーション4920を介して、従来の構成に対する実質的な改良を提供する。
【0362】
13.2 アプリケーションサービスグループ
アプリケーションサービスグループは、単に同時に動作するのではなく協力して動作し、機能の特定の集合を提供する複数のスマートカードアプリケーション4920から構成される。サービスグループの一部を形成するアプリケーション4920は、同時に実行されることを許されると共に、データの交換を行なう際に利用されるであろう通信手段(すなわち、イベントマネージャ4904)を共有する。このようなアプリケーション4920は、各々が特定のユーザインタフェース又はユーザインタフェースの集合に対応する機能の集合を提供するプロセス又は下位プロセスである。このアプリケーション4920は、可視のディスプレイを有しても有しなくても良い。
【0363】
図49に表される例を参照すると、サービスグループは、その一部を形成するアプリケーション4920が開始され、そのサービスグループをイベントマネージャ4904に登録するときに開始される。図49に示すように、第1のアプリケーション4926は2枚のスマートカード4924及び4926をそれ自体と関連付け、第2のアプリケーション4934はスマートカード4928、4930、及び4932を用いて動作可能である。従って、カード4922をリーダ1へと挿入する際に、カードデーモン4902は、ランチャ4910を介してアプリケーション4926を開始するイベントマネージャ4904にその発生を通知する。アプリケーション4926の開始により、サービスグループ4936が使用可能になる。このグループはアプリケーション4934を含む。現在確立されているサービスグループに対応するアプリケーションは、関連するスマートカードを挿入することによって開始されても良い。例えば、カード4922の抜取り及びカード4932の挿入は、アプリケーション4934を起動するように作用し、サービスグループ4936をアクティブ状態に維持する。更に、同じサービスグループの一部を形成するアプリケーションの開始は、同じサービスグループの他のアプリケーションの終了を引き起こさない。その他のアプリケーションはバックグラウンドで実行を継続する。
【0364】
サービスグループの終了は、空のリモートリーダ1に接触する、あるいは、サービスグループ4942中のアプリケーション4940に対応するカード4938などの別のサービスグループに対応するスマートカードを挿入することによって引き起こされる。サービスグループの終了により、現在そのサービスグループの一部として実行されている全てのアプリケーションも終了させられる。
【0365】
同じサービスグループ下で実行されるアプリケーションは、図49に示すように、サービスグループ定義のプロトコル4950によってイベントマネージャ4904を介して相互に通信しても良い。プロトコル4950において、アプリケーション(例えば、4926及び4934)間で送信されるデータパケットの形式及び内容は、同じサービスグループ内に共存するアプリケーションの作成者により定義されるべきである。
【0366】
図50に示されるのは、アーキテクチャ4900内のサービスグループの別の特徴である。ここでは、サービスグループは他のいずれかのサービスグループの一部として実行される1つ以上のアプリケーションを含んでも良い。これらのアプリケーションは、複数のサービスグループにまたがって要求される可能性があるサービスを提供する。このようなアプリケーションの一例は、ユーザの住所及びクレジットカードの詳細(ユーザが一度これらの詳細を提供することに同意した場合)を提供することができる個人識別サービスである。この点に関して、このようなサービスは、オンラインショッピング及びオンラインバンキングを含む金融取引を必要とする数多くのその他のサービス又はトランザクションのコンポーネントを形成しても良い。
【0367】
アーキテクチャ4900をサポートするためのアプリケーションの設計は、開発されるアプリケーションがアーキテクチャ4900により提供される新規の特徴を必要とするか否かによって、アプリケーション設計に対する既存のアプローチと同じであっても、あるいは、異なっていても良い。何らかの変形を施しても、既存のアプリケーションはアーキテクチャ4900の下で機能するであろう。このような変形の例としては、既存のアーキテクチャの下で稼働する各アプリケーションが、実行中のアプリケーションと同じ名前を有するサービスグループをもつ(すなわち、各アプリケーションはメンバを1つだけ有する独自のサービスグループを形成する)ことを想定できる場合、あるいは、一意的なグループ名を選択するその他の方法がある。この方法は、他のアプリケーションと協働しない既存のアプリケーションに対してグループ名をもたないことを含む。
【0368】
同じサービスグループ内の各アプリケーションは、同じ物理ハードウェア上で動作する必要はなく、OS定義の方法を使用することによって相互に直接通信可能でなくても良い。2つの通信方法は、イベントマネージャ4904において実現され、アプリケーション間通信の標準的な方法を提供するのが好ましい。これらの方法は:
(i)メッセージが1つのアプリケーションにより別のアプリケーションに送信されるデータグラムベースのプロトコルと、
(ii)アプリケーション4920により、同じサービスグループ中の任意のアプリケーション4920がメッセージを読むことができる共通の領域へとメッセージが掲示される掲示板に基づくプロトコルである。
【0369】
イベントマネージャ4904は、アプリケーション4920間で渡されるデータに対して構造を強制しない。全てのメッセージは既知の長さのただのデータブロックである。データに対して強制される他の任意の構造は、特定のサービスグループのアプリケーションにより理解されれば良い。データブロックには、ポスティングアプリケーションによってイベントマネージャ4904により格納される型(例えば、生データ、.wav、.docなど)が付与されても良い。
【0370】
サービスグループ中の1つのアプリケーションから同じサービスグループ中の別のアプリケーションへの任意の長さのデータの送信を可能にするのには、データグラム方式が使用される。この方法では、送信側アプリケーションが受信側アプリケーションの識別(ID)番号(上述のようにXidとも呼ばれる)を知っている必要がある。ID番号は、アプリケーション4920が開始されるときに対応するランチャ4910により生成され、アプリケーション4920は一意的に識別される。ID番号はイベントマネージャ4904のコンテキストにおいてのみ一意的である。このように、多くの実行中のアプリケーションは同じID番号をもつことができるが、全てのID番号はそのアプリケーションが接続される同じイベントマネージャ4904に接続される全てのアプリケーション4920において一意的である。イベントマネージャ4904は、2重のID番号が使用されるときにそれを検知することができるが、この検知を保証すると共に新規のアプリケーションの開始を防止するのは、対応するランチャ4910の責任である。
【0371】
データグラム方式を使用してメッセージを送信するために、送信側アプリケーションはイベントマネージャ4904から宛先アプリケーションのXidを取得し、Xidを使用してメッセージのアドレス指定を行ない、イベントマネージャ4904を介してメッセージを宛先アプリケーションに送信する。イベントマネージャ4904は、メッセージを含むパケットに対してデータ長及びヘッダの送信者フィールドが正しいことを確認する以外には何も行なわない。
【0372】
データグラム方式を利用可能にするには、イベントマネージャ4904はサービスグループ中で他のどのアプリケーションが実行中であるかを判定する何らかの方法をアプリケーションに提供しなければならない。この情報は、アプリケーションが他のアプリケーションの能力を判定するための何らかの方法も含む。アーキテクチャ4900では、アプリケーションがイベントマネージャ4904に登録するときにアプリケーションが列挙する機能文字列のリストを使用してこれが実行される。イベントマネージャ4904はどんな形であろうとこれらの機能を理解する必要がなく、機能のリストはサービス固有のものである。サービス中の他のアプリケーションのみが各機能文字列が何を意味するのかを理解する必要がある。
【0373】
イベントマネージャ4904は、この方法を使用することで送信可能なメッセージのサイズに上限を課しても良い。
【0374】
アーキテクチャ4900では、上述の掲示板により、データを即座にサービスグループ中の全てのアプリケーションに同報通信することができると共に、サービスグループ中のアプリケーションは中央のリポジトリにデータを格納することができる。これにより、いずれか1つのアプリケーションが常にサービスグループに存在する必要がなくなる。また、掲示板により、スマートカードは任意の順序で挿入することができ、サービスグループ中のアプリケーションは任意の順序で実行することができる。アプリケーションはサービスグループに提供するデータを掲示板に掲示し、アプリケーションがアクションをとる必要があるときには、必要なデータを求めて掲示板を検査することができる。
【0375】
データを掲示板に掲示するために、ポスティングアプリケーションは、掲示することが望まれるデータ、すなわち、記述文字列と、場合によっては、何らかの形態のタイピング情報(MIMEタイプなど)とをイベントマネージャ4904に送信する。アプリケーションがタイプ情報を供給しない場合、イベントマネージャ4904はデータにデフォルトのタイプ(例えば、デフォルトのバイナリデータ、MIMEタイプアプリケーション/オクテットストリーム)を割り当てることになる。イベントマネージャ4904は、掲示板のメッセージを識別するのに使用されるメッセージ識別子をこのメッセージに割り当てる。このメッセージ識別子は、他のアプリケーションにより掲示板からメッセージを取得するのに使用される。また、メッセージ識別子はポスティングアプリケーションが掲示板からメッセージを削除するのにも使用される。掲示板とサービスグループに対応する掲示板に残っているメッセージとは、サービスグループが終了させられると破壊される。
【0376】
掲示板からメッセージを取得するには、アプリケーションは必要なメッセージのメッセージ識別子を探さなければならない。アプリケーションは掲示板上のメッセージのリストを取得することができるが、このリストはメッセージ識別子、ポスタ識別子、及び掲示板上の各メッセージのメッセージ記述を含むであろう。第2の方法も、イベントマネージャ4904から実行中のアプリケーションのリストを取得することを含む。これにより、アプリケーションには、各アプリケーションがサービスに対して提供する機能が提供される。掲示板にメッセージを要求するアプリケーションは、情報を必要とするアプリケーションのアプリケーション識別子(Xid)を相互参照し、そのアプリケーションにより掲示される全てのメッセージを取得することができる。
【0377】
掲示板上のメッセージ及びメッセージ記述の双方の形式はサービスグループにより決定されるものであり、完全に任意のものであっても良い。イベントマネージャ4904はデータに対していかなる構造も強制しない。
【0378】
このような通信方法をサポートするために、イベントマネージャ4904には掲示板を維持することが要求される。イベントマネージャ4904にとっては、掲示板は単なる既知の長さのデータブロックのリストとして見える。アプリケーションが掲示板にメッセージを掲示するとき、イベントマネージャ4904はそのデータ及び長さを格納する。アプリケーションが掲示板からメッセージを読むとき、イベントマネージャ4904はそのデータをアプリケーションに送信する。また、イベントマネージャ4904は、掲示板の内容のリストを要求するアプリケーションに対してこれを作成する。
【0379】
イベントマネージャ4904は、サービスグループ中の全てのアプリケーションにより掲示することが可能な全てのメッセージの合計サイズのみならず、各アプリケーションが掲示することが可能なメッセージの合計サイズを制限しても良く、その結果、各アプリケーション及び各サービスグループはメッセージサイズ制限を有するようになる。また、アプリケーション及びサービスグループが掲示するメッセージの数を制限しても良い。メッセージの記述のサイズも最大長にまで制限されても良い。
【0380】
13.3 システム初期化
本節では、図48のソフトウェアアーキテクチャ4900を組み込むシステム600を最初に開始するプロセスを説明する。これは、分散型セットトップボックスシステム600Bのみならず、コンピュータシステム600Aにも関連する。
【0381】
最初に、マスタランチャ4908が開始され、ネットワーク220を介して通信ポートで応答の有無を聞き取る。イベントマネージャ4904が開始され、イベントマネージャ4904はマスタランチャ4908に接続する。
【0382】
アーキテクチャ4900のこれらの2つのコア部分を開始する順序は、システム600Aの場合には任意であるが、セットトップボックスシステム600Bにおいて使用されるときには明白な利点を有する。システム600Bでは、イベントマネージャ4904が開始されるときにはマスタランチャ4908は既に実行中であり、より多くのユーザがサービスを申し込むときにはより多くのイベントマネージャを開始し、ユーザがサービスを終了するときには実行中のイベントマネージャの数を減少させることができる。
【0383】
13.4 システム起動
本節では、図6A又は図6Bのハードウェアアーキテクチャ及び図48の代替のソフトウェアアーキテクチャを組み込むスマートカードシステムを開始するプロセスを説明する。この説明は、イベントマネージャ4904及びマスタランチャが既に実行中であり、オープンな接続を有することを前提とする。
(i)I/Oデーモン4902が開始され、イベントマネージャ4904への接続を開始する。
(ii)イベントマネージャ4904はI/Oデーモン4902からの接続を受け入れる。サービス課金を実行することができるのはこの段階である。例えば、ユーザが料金の支払いを済ませていない場合、接続を拒否することができる。
(iii)イベントマネージャ4904は、マスタランチャ4908にイベントマネージャ4904がどのポートで聞き取りを行なっているかを通知してマスタランチャ4908に新規のランチャ4910を要求し、入力接続を待つ。
(iv)マスタランチャ4908は新規のランチャ4910を開始し、新規のランチャ4910にイベントマネージャ4904のアドレス及びポート番号を教える。
(v)新規のランチャ4910はイベントマネージャ4904との接続を開始する。
(vi)イベントマネージャ4904は接続を受け入れる。
【0384】
システム600は、ユーザがスマートカードをリーダ1へと挿入し、最初のボタン押下を開始するときには、アプリケーション4920を開始する準備ができている。
【0385】
13.5 第1のスマートカードサービスの開始
本節では、図48のソフトウェアアーキテクチャを組み込むシステム600上で他のサービスが実行中でない場合にスマートカードサービスを開始するプロセスを説明する。これは、システムが最初に開始されるときの状況であり、タイムアウトを介して、あるいは、ユーザがスマートカード10を挿入せずにリモート操作装置1に接触したためにサービスが終了する場合にも発生する。
(i)ユーザがスマートカード10をリーダ1へと挿入し、タッチパネル8を押下する。
(ii)押下イベントがイベントマネージャ4904に送信され、イベントマネージャ4904はパケットの形式を変更し、ランチャ4910へと転送する。
(iii)ランチャ4910はパケットを受信し、いずれのサービスもアクティブでないことを認識し、スマートカード10のサービス識別子(ベンダ識別子及びアプリケーション識別子)及びサービス固有識別子(カード識別子)を伴ってディレクトリサービス4912に問合せを行なう。
(iv)問合せは適切なアプリケーション4920の位置を戻し、この位置をランチャ4910が取り込む。アプリケーション4920は、一般的に、ネットワーク220のいずれかの場所のサーバコンピュータ上の記憶装置からリモートで供給されるが、ランチャ4910に対してローカルに実行されなければならない場合もある。高度なシステムでは、アプリケーションはランチャからリモートで実行されても良い。
(v)ランチャ4910は、イベントマネージャ4904に新規のアプリケーション4920が開始されることを通知する。
(vi)アプリケーション4920は、実行されるランチャへのダウンロードを終了すると、ランチャ4910により開始される。
(vii)アプリケーション4920はイベントマネージャ4904との接続を開始し、イベントマネージャ4904がその接続を受け入れると、ランチャ4910に登録する。これは、アプリケーション4920がどのサービスグループの一部であるか及びアプリケーションがどの機能を実行可能であるのかを含む。
(viii)ランチャ4910は、新規のアプリケーション4920にフォーカスが得られることを通知する。
【0386】
この段階でアプリケーション4920は開始され、イベントを受信できる状態になる。リーダ1により生成されるPRESSメッセージ、RELEASEメッセージ、及びMOVEメッセージは、そのアプリケーションにより意図される限り、イベントマネージャ4904によりアプリケーション4920へと転送される。アプリケーション4920は、登録が完了するまでいかなる形であろうとイベントマネージャ4904と対話することができない。更に、イベントマネージャ4904はイベントをアプリケーションへと転送することはない。イベントマネージャ4904が登録されていないアプリケーション4920から受信するアプリケーション登録イベント以外のいかなるイベントも破棄されることになる。
【0387】
13.6 アプリケーションの開始、制御、及び停止
図56(a)及び図56(b)は、ソフトウェアアーキテクチャ4900を組み込むシステム600上でユーザにサービスを提供するために、複数のアプリケーション4920のうちの1つのアプリケーション(アプリケーション#1〜#n)を開始、制御、及び停止する方法5600を示す。方法5600のプロセスは、システム600AのCPU205又はシステム600BのCPU4305などのCPUにより実行される。方法5600を示すソフトウェアプログラムは、システム600AのCD−ROM212又はシステム600Bのメモリ4306などのメモリ媒体に格納される。ユーザがスマートカード10をリーダ1に挿入し、タッチパネル8を押下して所望の印を選択すると、リーダ1のCPU45はスマートカード10からカードヘッダ1100及び選択された印と関連付けられるデータを読み、選択された印と関連付けられた押下イベント(例えば、押下メッセージ)をイベントマネージャ4904に送信する。イベントマネージャ4904はパケットの形式を変更する。イベントマネージャ4904は、押下パケット(例えば、EM-READER PRESS)をランチャ4910に送信する。ソフトウェアプログラムはCPUにより実行されるが、このCPUは、カードインタフェース(デーモン)4902がリーダ1から押下イベントを受信し、それをイベントマネージャ4904に送信すると、少なくとも同じ計算装置のカードインタフェース(デーモン)4902、イベントマネージャ4904、ランチャ4910、及びアプリケーション4920を実行する。これに対し、ソフトウェアプログラムが別々の計算装置の各CPUにより実行される場合、イベントマネージャ4904を実行する第1の計算装置の第1のCPUがステップ5603から5608を実行し、少なくともランチャ4910及びアプリケーション4920を実行する第2の計算装置の第2のCPUがステップ5609から5636を実行する。
【0388】
ステップ5603において、イベントマネージャ4904を実行することによって、CPUはカードインタフェース4902を介してリーダ1から押下イベントを受信し、次のステップ5605において、押下イベント中のサービス識別子(ベンダ識別子及びアプリケーション識別子)が既に実行中のアプリケーション4920のうちのフロントアプリケーション(例えば、アプリケーション#1)のサービス識別子と一致するか否かを判定する。次のステップ5605においてマッチングテーブルを使用してサービス識別子がフロントアプリケーション(例えば、アプリケーション#1)のサービス識別子と一致すると判定される場合、次のステップ5608においてイベントマネージャ4904を実行することによって、CPUは押下パケットをフロントアプリケーションへと転送し、方法5600は終了する。アプリケーション4920の各アプリケーションと対応するサービス識別子との間の関係を有するテーブルが、メモリ206又はメモリ4306のRAMに格納される。ステップ5605において、サービス識別子がフロントアプリケーションのサービス識別子と一致しないと判定される場合、次のステップ5607において、CPUはイベントマネージャ4904からランチャ4910へと押下パケットを転送する。次のステップ5609において、ランチャを実行することによって、CPUはサービス識別子を伴ってディレクトリサービス4912に問合せを行ない、サービス識別子に対応する新規のアプリケーション(例えば、アプリケーション#2)の位置を受信する。次のステップ5611において、ランチャ4910を実行することによって、CPUはその位置から新規のアプリケーションを取り込む。次のステップ5613において、ランチャ4910を実行することによって、CPUは新規のアプリケーション(例えば、アプリケーション#2)を実行する。次のステップ5615において、CPUは新規のアプリケーションとイベントマネージャ4306との間の接続を開始する。イベントマネージャ4306が接続を受け入れると、CPUは新規のアプリケーションをランチャ4910に登録し、アプリケーションはランチャ4910にどのサービスグループの一部であるかを通知する。次のステップ5616において、CPUはメモリ206又はメモリ4306のRAMに格納されたサービスグループテーブルを使用して、新規のアプリケーションが現在実行中のアプリケーションとサービスグループを共有するか否かを判定する。各サービス識別子と対応するサービスグループとの間の関係を有するテーブルは、メモリ206又はメモリ4306中のメモリのRAMに格納される。例えば、テーブルにおいて、サービス識別子1(アプリケーション#1)及びサービス識別子3(アプリケーション#3)がサービスグループAに対応し、サービス識別子2(アプリケーション#2)及びサービス識別子4(アプリケーション#4)がサービスグループBに対応する。次のステップ5616において、新規のアプリケーションが現在実行中のアプリケーションとサービスグループを共有すると判定される場合、次のステップ5635においてランチャ4910を実行することによって、CPUは現在のアプリケーション(フロントアプリケーション)にフォーカスが失われることを通知する。次のステップ5636においてランチャ4910を実行することによって、CPUは新規のアプリケーションにフォーカスが得られることを通知し、方法5600は終了する。この場合、CPUは現在のアプリケーション(フロントアプリケーション)の実行をバックグラウンドで継続するが、リーダ1からはイベントを受信しない。現在のアプリケーションを実行することによって、CPUは同報メッセージ及びメッセージを特定のアプリケーションに送信することができるが、サービスグループから外れることはできない。
ステップ5616において、新規のアプリケーションが現在実行中のアプリケーションとサービスグループを共有しないと判定される場合、ステップ5617においてランチャ4910を実行することによって、CPUは現在実行中のアプリケーションに終了するように通知し、タイムアウトを設定する。次のステップ5621においてランチャ4910を実行することによって、CPUはタイムアウトを待ち、新規のアプリケーションを除く残りのアプリケーションを終了させる。次のステップ5623においてランチャ4910を実行することによって、CPUはイベントマネージャ4904に終了した又は終了させられたアプリケーションを通知する。次のステップ5636においてランチャ410を実行することによって、CPUは新規のアプリケーションにフォーカスが得られることを通知し、方法5600は終了する。この場合、CPUは新規のアプリケーションを実行中であり、EM-READER PRESS、EM-READER-RELEASE、及びEM-READEF MOVEなどのそのアプリケーション用の押下パケットを受信する。システム600A又は600Bは1つだけアプリケーションを有する新規のサービスを実行中である。
【0389】
13.7 2つのアプリケーション間でのデータの受け渡し
本節では、図48のソフトウェアアーキテクチャを組み込むシステム600上でデータグラムプロトコルを使用して2つのアプリケーション4920(アプリケーション#1)及び4920(アプリケーション#2)間でデータの受け渡しを行なうプロセスを説明する。この方法では、送信側アプリケーション#1が受信側アプリケーション#2のアプリケーション識別子(Xid)を知っている必要がある。
(i)送信側アプリケーション#1は送信を希望するデータを収集する。
(ii)送信側アプリケーション#1はランチャ4910に現在のサービスグループで実行中のアプリケーションのリストを要求する。
(iii)ランチャ4910はアプリケーション#1に現在のサービスグループ中の全てのアプリケーションのリストを送信する。このリストは、アプリケーションが提供した記述文字列のみならず、各アプリケーションがランチャ4910に実行可能であると通知した各機能を含む。このリストの順序では、直前のアプリケーションが先頭に列挙される。
(iv)送信側アプリケーション#1は、データの適切な受信者の有無を調べる。受信者が存在しない場合、処理の進め方を決定するのはアプリケーション#1の役割である。アプリケーション#1は、例えば、データを送信しなくても良く、場合によっては、ユーザに別のスマートカードを挿入するように要求しても良い。カードの挿入により所要のアプリケーションが開始されるであろう。
(v)適切な受信者が存在する場合、送信側アプリケーション#1はイベントマネージャ4904を介して受信側アプリケーション#2にデータを送信する。
(vi)イベントマネージャ4904はメッセージヘッダをチェックして送信側アプリケーション#1がデータ長及び送信者フィールドを正しく記入していることを確認し、メッセージを受信側アプリケーション#2に渡す。このようなアプリケーション#2が実行されていない場合、イベントマネージャ4904はメッセージを破棄し、送信側アプリケーション#1にエラーメッセージを戻す。
【0390】
13.8 掲示板へのデータの掲示
本節では、ソフトウェアアーキテクチャ4900を組み込むシステム600上で共通の掲示板にデータを掲示するプロセスを説明する。
(i)ポスティングアプリケーション4920は掲示板に掲示することを希望するデータを収集する。
(ii)ポスティングアプリケーション4920はデータをその簡潔な記述と共にイベントマネージャ4904に送信する。
【0391】
13.9 掲示板からのデータの取得
本節では、ソフトウェアアーキテクチャ4900を組み込むシステム600上で別のアプリケーションにより予め掲示板に掲示されているデータを取得するプロセスを説明する。
(i)要求元アプリケーション#2は、イベントマネージャ4904に掲示板上のメッセージのリストを要求する。
(ii)イベントマネージャ4904は、アプリケーション#2に掲示板上のメッセージのリストを送信する。このリストは、データの簡潔な記述、メッセージを掲示板に掲示したアプリケーション4920に対するアプリケーション識別子(Xid)、及び掲示板上の全てのメッセージに対するメッセージ識別子を含むであろう。
(iii)アプリケーション#2は、イベントマネージャ4904にメッセージ識別子を用いて特定のメッセージを要求することも、ランチャ4910に現在実行中の全てのアプリケーションのリストを要求することもできる。
(iv)アプリケーション#2が実行中のアプリケーションのリストを要求した場合、ランチャ4910はそれをアプリケーション#2に送信する。このリストは、アプリケーション識別子(Xid)と対応するアプリケーションがランチャ4910に実行可能であると報告した機能のリストとを含むであろう。
(v)要求元アプリケーション#2は、求める機能を実行するアプリケーションからの全て又は一部のメッセージを見つけることができる。
【0392】
13.10 掲示板からのデータの削除
本節では、ソフトウェアアーキテクチャ4900を組み込むシステム600上で同じアプリケーション又は別のアプリケーションにより予め掲示板に掲示されているデータを削除するプロセスを説明する。
(i)要求元アプリケーション#2は、イベントマネージャ4904に掲示板上のメッセージのリストを要求する。
(ii)イベントマネージャ4904は、アプリケーション#2に掲示板上のメッセージのリストを送信する。このリストは、データの簡潔な記述、ポスティングアプリケーションのアプリケーション識別子(Xid)、及び掲示板上の全てのメッセージに対するメッセージ識別子を含むであろう。
(iii)アプリケーション#2は、メッセージ識別子を指定することによってイベントマネージャ4904に特定のメッセージを削除するように要求する。
【0393】
13.11 適用例
例A: カード配列
実施される可能性のあるアプリケーションカード配列は幾つも存在する。アーキテクチャ4900では、アプリケーション4920に対してどのカード配列又はカード配列の組み合わせが採用されるかに関して制約がない。
【0394】
図51Aに示すサービスグループ内の順次カード配列では、アプリケーションの特定の集合に対するスマートカード10は指定の順序で挿入される必要がある。例えば、カードAの後には、カードB、カードCが続き、抜き取り及び/又は再挿入の場合でも同じ配列に従う。
【0395】
サービスグループ内の階層カード配列では、アプリケーションの特定の集合に対するカードは図51Bに示すようにツリー状に挿入される必要がある。カードAが挿入される場合、カードB又はカードCのみを挿入しても良い。カードBが抜き取られる場合、カードAを再挿入しなければならない。カードCが挿入される場合、カードDのみが挿入されても良く、カードDが抜き取られる場合、カードCのみが挿入されても良い。
【0396】
サービスグループにおける完全網目状カード配列により、アプリケーションの集合に対するカードを任意の順序で挿入・使用できる。
【0397】
例B: ピザ注文サービス
従来のピザ注文アプリケーションでは、ピザの種類に関して複数の選択肢(vegetarian、supreme、及びmeat loversなど)が提示されているが、トッピングのカスタマイズ又は特別割引の利用に対する機能は提供されていない。
【0398】
アーキテクチャ4900の下でJoe's Pizzeriaサービスグループを構成するアプリケーションの集合の一例は以下のようになるであろう:
(i)Joe's Pizzaメニュー、
(ii)トッピングスペシャリスト、
(iii)現在の特別割引、及び
(iv)個人識別子
これらのアプリケーションの各々は、他のアプリケーションと協働し、フル機能のピザ注文サービスを創設するように仕向けることができる。Joe's Pizzaメニューアプリケーションは、ピザの種類(vegetarian、supremeなど)、ドリンク(コーラ、ライムなど)、及びサイドメニュー(ガーリックブレッド、パスタなど)を顧客が選択することができるユーザインタフェースを提供する。また、このアプリケーションは、現在の注文の買い物かご形式のリストを保持し、注文をリセットするためのボタン及び完了するためのボタンをスマートカードに設ける。
【0399】
トッピングスペシャリストアプリケーションは、顧客が現在注文予定のピザのリスト内を移動し、選択したピザにカードの表面に印刷された一連のトッピングの中からトッピングを追加/削除できるユーザインタフェースを提供する。注文可能なピザのリストは実行中のJoe's Pizzaメニューアプリケーションから得られる。ピザのトッピングの変更は、ピザの注文の修正のためにJoe's Pizzaメニューアプリケーションへと伝えられるであろう。
【0400】
現在の特別割引アプリケーションは、Joe's Pizzeriaで利用可能な現在の特別割引のリスト内を移動するためのコントロールを提供する。選択される特別割引は、現在の注文に適用されるようにJoe's Pizzaメニューアプリケーションへと伝えられる。
【0401】
個人識別子アプリケーションは、ユーザが提供を希望する詳細によって、ユーザの自宅の住所及び自宅の電話番号をJoe's Pizzaメニューアプリケーションへと選択的に伝える方法を提供する。
【0402】
例C: 写真現像サービス
従来の写真アルバムアプリケーション及びTシャツアプリケーションでは、現在選択されている写真の送受信のためにクリップボードが共有される(ファイルとして)。しかし、写真の修整(例えば、トリミング又は輝度の向上)のための機能、あるいは、複数の連結されたカードを有する機能はない。これらの連結されたカードは1本のフィルム全体を表し、各カードは現在最大20枚の写真のみを含み、各写真はボタンとして機能するのに十分な大きさのアイコンにより表される。
【0403】
アーキテクチャ4900に関して、写真現像サービスは以下の1組のカードを有するように設計されても良い:
(i)Film_1a、
(ii)Film_1b、
(iii)Tシャツプリンタ、及び
(iv)フォトエンハンサ
Film_1aカード及びFilm_1bカードは、それぞれ40枚の写真を含む1本のAdvantix(Kodak Corp, USAの登録商標)全体を表す。いずれのカードを最初に挿入しても良い。いずれかのカードが一度挿入されると、挿入されたカードの表面に印刷された写真への直接アクセスを用いることで双方のカードにわたる写真一式へのアクセス権が提供される。これは、スライドショー機能が双方のカードに対応する写真を循環させるであろうことを意味する。各カードは、写真現像サービスグループ中の別のアプリケーションを用いてユーザ用のサービスグループクリップボードに特定の写真参照を追加するためのボタンを有し、アプリケーションは現在閲覧中の写真への参照を戻す機能を提供するであろう。
【0404】
Tシャツプリンタアプリケーションは、直前に見た写真(フィルムアプリケーションから得られるものへの参照)を使用してTシャツ転写物をインスタントで印刷するか、あるいは、クリップボードにある1組の写真からTシャツ転写物を作成する機能を提供する。
【0405】
簡易な写真編集サービスの一部として、フォトエンハンサアプリケーションは、直前に見た写真(Tシャツアプリケーション及びフィルムアプリケーションのうちの直前にフォアグラウンドにあった方から得られる)に対して動作する。フォトエンハンサは、自動トリミング、鮮鋭化、ぼかし、淡色化、暗色化などの操作を提供しても良い。このとき、変更をフォトサーバに戻して永続化することができる。
【0406】
例D: ビデオ電子メールサービス
従来のビデオ電子メールアプリケーションは、カードの表面に記載されるビデオ電子メールユーザにビデオ電子メールメッセージを送信する手段を提供する。設計を幾らか変更すれば、アーキテクチャ4900によるビデオ電子メールサービスを創設することが可能である。このサービスでは、スマートカード名刺をアドレス帳の所有者に供給する複数ユーザからアドレス帳を編纂することができる。ビデオ電子メールサービスを形成するアプリケーションは以下の通りである:
(i)ビデオ電子メール送信、
(ii)ビデオ電子メールメールボックス、
(iii)ビデオ電子メールアドレス帳、及び
(iv)名刺
ビデオ電子メール送信アプリケーションは、挿入される個人識別カード又は挿入される名刺からアドレスが得られる点を除き、従来のアプリケーションとほぼ同様に動作する。
【0407】
ビデオ電子メールメールボックスアプリケーションは、リモートサーバからビデオ電子メールメッセージを取得する機能を提供すると共に、ビデオ電子メール送信アプリケーションにより返信アドレスとして使用される送信者のアドレスを提供する。
【0408】
アドレス帳機能は、ビデオ電子メールアドレス帳アプリケーションにより提供される。このアプリケーションにより、ユーザは挿入される様々な名刺、個人識別子カード、又はビデオ電子メールメールボックスカードからアドレスのリストを増強することができる。ビデオ電子メール送信アプリケーションにより使用するため、アドレスのリストから1つ以上のエントリが選択されても良い。
【0409】
例E: 買い物かごサービス
従来のソフトウェアアーキテクチャでは、オンラインショッピングを提供するアプリケーションは、買い物かご手段、注文手段、料金請求手段、及び発送手段を含む独自の購入システムを維持する必要があった。アーキテクチャ4900の一部として利用可能な特徴を利用する買い物かごサービスは、これらの機能が各オンラインショッピングアプリケーションから分離できるようにし、他の機能のためのユーザインタフェース領域を広げるであろう。このような買い物かごサービスの一部を形成するであろうアプリケーションは以下の通りである:
(i)電子配送買い物かご、
(ii)Davy Jonesオンライン、及び
(iii)Pace Bros.オンライン
電子配送買い物かごアプリケーションは、総合買い物かご管理機能、支払機能、及び注文機能を提供する。
【0410】
Davy Jonesオンラインアプリケーション及びPace Bros.オンラインアプリケーションは、対応するデパートから仕入れ可能な品目のリストを関連する品目記述と共に閲覧する機能を提供する。購入を希望する品目が見つかったときには、電子配送買い物かごアプリケーションを経由してその品目を買い物かごに追加し、注文・配送に備えることができる。
【0411】
先の説明から明らかなように、管理プロセスの部門分け及びアプリケーションの適切な起動を介して柔軟性の拡張を許容するカードインタフェースシステムを実現するのにアーキテクチャ4900を使用しても良い。これにより、アプリケーションは機能的結果を達成するために協力的に動作することができる。更に、複雑度に見合ったプラットフォームで手順を動作させる能力を介して、種々の複雑度のハードウェアプラットフォームからアーキテクチャ4900の種々のコンポーネントを動作させることができる。このようなプラットフォームは、処理能力の限られたローエンドのセットトップボックスから、家庭用PC及びリモートサーバコンピュータにまで及ぶ。特に、「ダム」セットトップボックスの場合、カードデーモン4902はセットトップボックスの内部から1つ以上のリモートサーバコンピュータの全てのプロセスのバランスにより実行されるであろう。これに対し、スマートセットトップボックス又は家庭用パーソナルコンピュータの場合、全てのプロセスは、ネットワーク220を介する外部通信が必要不可欠な場合を除き、1つのハードウェアの内部から動かされるであろう。
【0412】
また、アーキテクチャ4900は、不正なデータ吸上げ及び詐欺行為からユーザ及びベンダの双方を保護するために、特定のアプリケーションに適した機密保護モデルをサポートするように拡張することができる。
【0413】
イベントコマンドの導管として作用するイベントマネージャ4904により、アーキテクチャは通信プロトコルのある範囲のバージョンにわたって開発されたアプリケーションと共に動作することができる。このようなアーキテクチャは、通常、時の経過と共に開発される可能性があるからである。
【0414】
アーキテクチャ4900により、カードインタフェースシステム600は、カードアプリケーションが予期される動作モードに従っていないときでも機能を継続することができる。これは、アプリケーションの突然の終了、コマンドによる終了の拒否、及びシステム600への不正な又は余分なデータの送信を含む。アーキテクチャ4900は、同じサービスグループに所属するアプリケーションの各カードによってマルチカードアプリケーションをサポートし、それにより、カードが抜き取られて新規のカードが挿入されるときにアプリケーション実行の維持が保証される。
【0415】
13.12 アプリケーション管理システム
コンピューティングリソースを過負荷状態にしたり、適切な応答を保証したりすることなく複数のアプリケーションが同時に動作可能であるようにするために、サービスグループの概念、その確立、及びその消滅を利用してアーキテクチャ4900の説明を行なってきた。
【0416】
複数のアプリケーションを考慮する際の代替のアプローチは、アプリケーション間のデータフローがデータの作成者からデータの消費者への方向であると解釈することから生じる。図55は有向グラフを示し、グラフ方向は、群機能を実行するために消費者から作成者へと向かう。この場合、Tシャツは名前と表面に転写される写真とを有し、そのデータは複数の他のアプリケーションから得られる。このようなグラフ構造内のアプリケーションの管理は、グラフの各ノードのアクセス可能性によって決まる。具体的には、グラフ中のノードが到達不可能になると、そのノードにおけるアプリケーションは認識している機能を実行することができないので、そのアプリケーションは終了させられるべきである。更に、そのアプリケーションの生成物の消費者がそのサービスに対する登録を解除するときには、ノードへのリンクは削除されるべきである。アプリケーションは開始されるとツリーに配置される。アプリケーションが消費者が望む種類の作成者である場合、アプリケーションはツリー中のそのノードの下に配置される。
【0417】
上述のように、アプリケーション4920は、アーキテクチャ200に関して先に説明したサービス識別子と同等の対応するベンダ識別子及びアプリケーション識別子により参照される。アプリケーション識別子(すなわち、Xid)は、既に実行中のアプリケーションを起動する際の迅速なマッチング用のユニークキーとして使用される。アプリケーション識別子は、ベンダ識別子及びカード識別子(カード識別子はアーキテクチャ200を参照して先に説明したサービス固有識別子と同等である)と共にカード上に格納されるものと、開始されるときにシステムによりアプリケーションに割り当てられるものとの2つが存在する(後者のアプリケーション識別子は、ここではコンポーネント識別子又はXidとも呼ばれ、前者のアプリケーション識別子は上述のようにサービス識別子に関連する)。
【0418】
各アプリケーションは、識別のためにXidを使用することで必要に応じて機能の作成者又は消費者として登録しても良い。アプリケーションは、ユーザインタラクションを介して特定の時点で何が必要かを認識している。例えば、ユーザはアプリケーション内を「写真追加」画面まで移動する。ここで、アプリケーションはフォト消費者として登録しても良い。この点に関して、サービスグループアプローチは実際には大まか過ぎるので、登録はサービスグループではなく機能に基づいて行なわれるのが好ましい。更に、このアプローチでは、サービスグループ中の全てのアプリケーションがそのサービスグループにより提供される全ての機能をサポートしない限り、作成者が必要とする特定のサービスを提供することができない可能性があるときに、アプリケーションは消費者/作成者関係において別のアプリケーションにリンクすることができない。
【0419】
アプリケーションは他のアプリケーションから2つ以上の機能を要求する可能性があるので、このようなモデルは実現用の2つのオプションを提示する。
【0420】
1.グラフ中の各ノードは、他のどのノードに対しても接続を1つだけ有する。これは、接続が消費者/作成者関係に含まれるサービスのリストも含まなければならないことを意味する。消費者がサービスに対する登録を解除するたびにリストエントリが削除される。接続用のサービスのリストが空になると、接続は削除される。接続が削除されると、その接続によりリンクされる作成者もチェックを受ける。作成者ノードが既に他のノードに接続していない場合、そのノードは削除されるであろう。
【0421】
2.このオプションは、サービスのリストを保持する代わりに、各サービスが消費者/作成者ノード間における別々の接続である点を除いては(1)と同様である。このため、2つのアプリケーション間には複数の接続が存在するであろう。消費者がサービスに対する登録を解除するとき、その接続は削除される。作成者が既に接続されていない場合、消費者は終了する。
【0422】
この提案は、それぞれが現在リーダ1に挿入されているスマートカードと関連付けられるアプリケーションを特定のユーザ動作以外のイベントにより終了させることができる点において問題である。これは、ユーザの観点から混乱を招く恐れがある。従って、アプリケーションの終了に対する代替のアプローチが望まれる。
【0423】
このような代替のアプローチでは、アーキテクチャ4900は、上述のように特定のサービスグループのメンバである任意のアプリケーション4920に特に依存することなく動作しても良いが、「主」サービスグループと呼ばれるグループの一時情報を介して動作する。主サービスグループは、任意のアプリケーション4920が、作成者である場合、消費者である場合、作成者兼消費者である場合、及び作成者でも消費者でもない場合のいずれに分類されるかによって判定される2つ以上の現在のアプリケーション間の一時機能的関係から生じる。
【0424】
アプリケーション4920に対するこのような管理システムは、同じサービスグループ中のアプリケーションの作成者/消費者対又はアプリケーションが双方の基準を満たす場合には単一のアプリケーションが登録されるときに形成される「主」サービスグループの概念を中心とする。例えば、アプリケーションAc及びApが同時に動作するときにはサービスグループAが主となり、作成者−消費者対に適合する。一方、作成者−消費者対に適合するAcBp又はApBcは主サービスグループを作成しない。この管理システムによると、主サービスグループが形成されるとき、そのグループを共有しない全てのアプリケーションが終了させられる。双方が同時に登録される場合、主サービスグループは、第2の主サービスグループと共に存在しても良い。例えば、アプリケーション#1が開始されてApBpを登録し、アプリケーション#2が開始されてAcBcを登録する場合、A及びBは主になる。2つ以上の主サービスグループが存在するためには、開始される新規のアプリケーションが作成者−消費者対を確立する各グループに登録するときにそれらのサービスグループが形成されなければならない。サービスグループを形成するアプリケーションの作成者/消費者対は、主サービスグループが主グループの「従属者」になった後に登録される。従属グループの従属グループが形成されても良い。従属者の従属者は、従属者の作成者が既に第2の従属者に対する消費者として登録されているときに形成される。
【0425】
このような管理構造の最終結果は、ユーザが望む最終結果を達成するためにデータの受け渡しを行なう相互作用アプリケーションのツリー又はグラフの作成及び解体である。具体的には、このような結果は、ピザ注文サービスに対する上述の例Bとは対照的に、利用されるアプリケーションのフェースから容易に明らかにならない可能性がある。このアプリケーション管理構造は、以下の例を参照することで最も良く説明される。
【0426】
以下の例は、複数のアプリケーションを参照する。その詳細が以下の表4に記載される。
【0427】
【表4】
【0428】
例F:
この例では、ユーザはカード上に受信者の名前、定番のメッセージ、及び写真を有するグリーティングカードを作成することを望む。表4のカードを使用する第1のステップは、ユーザがCardMakerアプリケーションカードをリーダ1へと挿入することであろう。このような動作によりアプリケーションが開始され、サービスグループA及びZの消費者として登録される。アプリケーションは、そのサービスグループへの所属を動的に変更しても良い。例えば、CardMakerが開始され、ユーザに以前に作成したカードと同一のカードの作成を希望するか否かを尋ねる画面表示を提示しても良い。「NO」と回答すると、新規のカードが作成されることになるので、CardMakerはID1及びPhoto1に消費者として登録する。この段階におけるプロセスツリーは図53Aに示される。次に、ユーザは写真が要求されていることを認識し、CardMakerアプリケーションを抜き取り、Photo1アプリケーションを挿入することによってその写真を提供する。CardMakerアプリケーションはまだ機能を実行しなければならないので、リーダ1から抜き取っても動作を継続する。Photo1アプリケーションの挿入により、図示するようにAc及びApに主サービスグループをクレートに詰めるが、これは、CardMakerアプリケーションが写真を要求し、Photo1アプリケーションがその写真を供給することができることを意味する。Photo1アプリケーションは、写真にアクセスするためにPINを必要とするので、構成は図53Bに表すようになる。Photo1上の全ての写真が使用のためのロック解除にPINを必要とする訳ではないので、考慮中の場合のように、処理を進めるのにPINを必要とするときにはPhoto1はPcとしてのみ登録する。図53Cによると、続いてPINカードが提供される。図53Cから明らかなように、第2の作成者−消費者対が形成され、この場合、PINの提供によりPhoto1カードはユーザにより選択された写真をCardMakerアプリケーションに供給することができる。これらのタスクが完了すると、プロセスツリーの左側の枝が消去され、図53Dに示すように、対応する「実行済」アプリケーションがイベントマネージャ4904から登録を解除する。プロセスを完了する次のステップは、所望の名前を有するカードを挿入することである。ここでは、この名前は、図53Eに示すアプリケーションID1から得られる。このアプリケーションが所望の名前を供給するので、CardMakerアプリケーションは満足し、それにより、他の全てのアプリケーションは登録を解除し、終了できるようになる。CardMakerアプリケーションは他のアプリケーションとのインタラクションなしに所要のカードを出力することができる。
【0429】
代替のアプローチでは、写真及び名前の双方にアクセスするのにPINアプリケーションが必要とされても良い。双方の写真カードに対するPINが同じである場合に限り、PINアプリケーションカードは1度だけの挿入で良い。図54に示すようなプロセスツリーが形成されるであろう。この例では、PhotoIDは作成されるカードの受信者の写真を有しても良く、Photo1は写真に重ねる魅力的な背景写真を有しても良いので、PhotoID及びPhoto1が使用される。
【0430】
図54は、プロセスツリー中のノードに対する複数のリンクが許容され、到達不可能なノード(リンクなしのノード)上のアプリケーションが終了させられることを例証する。
【0431】
実行中のアプリケーションに対する上限は7に設定されるのが好ましい。この数を超える場合、アプリケーションの終了によりプロセスツリー中の最古の葉アプリケーションが開始される。
【0432】
以上の記述では、本発明の幾つかの構成及びこれらの構成に対する変形を説明しているに過ぎず、本発明の趣旨から逸脱することなく、変形及び/又は変更を行なうことができる。各実施形態は例示のためのものであり、限定することを意図しない。
【図面の簡単な説明】
【図1】 図1は、読取り装置及び関連するカードの斜視図である。
【図2】 図2は、図1に示すカードの反対側の斜視図である。
【図3】 図3は、図1に示すカードを線III−IIIに沿って切断したときの長手方向の横断面図である。
【図4】、
【図5】 図4及び5は、図1に示すカードの代替のカード構成の裏面の斜視図である。
【図6(a)】 図6(a)は、カードインタフェースシステムのハードウェアアーキテクチャを示す図である。
【図6(b)】 図6(b)は、カードインタフェースシステムの別のハードウェアアーキテクチャを示す図である。
【図7】 図7は、図6(a)及び図6(b)の汎用コンピュータの概略ブロック図である。
【図8】 図8は、カードインタフェースシステムアーキテクチャの概略ブロック図である。
【図9】 図9は、カードインタフェースシステムの概略ブロック図である。
【図10】 図10は、図1のリーダの内部構成を示す概略ブロック図である。
【図11】 図11は、図1のカードに格納されたカードヘッダのデータ構造を示す図である。
【図12】 図12は、図11のヘッダの各フィールドの記述を示す図である。
【図13】 図13は、図11のヘッダに含まれる各フラグの記述を示す図である。
【図14】 図14は、図1のカードに対するオブジェクト構造の各フィールドの記述を示す図である。
【図15】 図15は、図14のオブジェクト構造に対するフラグの記述を示す図である。
【図16】 図16は、図14のオブジェクト構造に対する各オブジェクト種別の記述を示す図である。
【図17】 図17は、図14のオブジェクト構造によるユーザインタフェースオブジェクト構造に対する各フィールドの記述を示す図である。
【図18】 図18は、図14のオブジェクト構造による各ユーザインタフェースオブジェクトフラグに対する記述を示す図である。
【図19】 図19は、図1のリーダから送信されるメッセージヘッダの形式を示す図である。
【図20】 図20は、図19のヘッダに対するメッセージイベント種別を列挙するテーブルを示す図である。
【図21】 図21は、単純なメッセージの形式を示す図である。
【図21(a)】 図21(a)は、INSERTメッセージの形式を示す図である。
【図22】 図22は、MOVEメッセージの形式を示す図である。
【図23】 図23は、PRESSメッセージ及びRELEASEメッセージの形式を示す図である。
【図24】 図24は、図6のシステム内のメッセージの流れを示すデータフロー図である。
【図25】 図25は、図1のリーダにより実行される読取り方法を示すフローチャートである。
【図26】 図26は、図25の方法の間に実行される図6のシステムを初期化する方法を示すフローチャートである。
【図27】 図27は、図25の方法の間に実行される図1のカードをチェックする方法を示すフローチャートである。
【図28】 図28は、図25の方法の間に実行される図1のリーダのタッチパネルを走査する方法を示すフローチャートである。
【図29】 図29は、図25の方法の間に実行される10ミリ秒待機方法を示すフローチャートである。
【図30】 図30は、図6のシステムのイベントの概要を示すフローチャートである。
【図31】 図31は、図30のプロセスの間にイベントマネージャにより実行されるプロセスを示すフローチャートである。
【図32】 図32は、図30のプロセスの間に実行される新規のアプリケーションを開始するための方法を示すフローチャートである。
【図33】 図33は、図30のプロセスの間に実行されるアプリケーションを終了する方法を示すフローチャートである。
【図34】 図34は、永続的アプリケーションに対する現在のセッションを終了する方法を示すフローチャートである。
【図35】 図35は、フォーカス変更を実行する方法を示すフローチャートである。
【図36】 図36は、ランチャにより実行される方法の概要を示すフローチャートである。
【図37】 図37は、図36の方法の間に実行されるアプリケーションを変更する方法を示すフローチャートである。
【図38】 図38は、図36の方法の間に実行される新規のアプリケーションを登録する方法を示すフローチャートである。
【図39】 図39は、ランチャからイベントを受信するときにアプリケーションにより実行される方法を示すフローチャートである。
【図40】 図40は、ランチャからイベントを受信するときにブラウザコントローラアプリケーションにより実行される方法を示すフローチャートである。
【図41】 図41は、ブラウザアプリケーション方法を示すフローチャートである。
【図42】 図42は、システム600のセットトップボックスをより詳細に示す概略ブロック図である。
【図43】 図43は、「ボトムエントリ」型のリーダの斜視図である。
【図44】 図44は、図43のリーダの平面図である。
【図45】 図45は、図43のリーダにカードを挿入するユーザを示す図である。
【図46】 図46は、カードが完全に挿入された後に図43のリーダを操作するユーザを示す図である。
【図47(a)】 図47(a)は、図44の線V−Vに沿って切断したときの長手方向の横断面図である。
【図47(b)】 図47(b)は、カードがリーダのレセプタクルに部分的に挿入された場合の図47(a)と同様の図である。
【図47(c)】 図47(c)は、カードがリーダのテンプレートレセプタクルに完全に挿入された場合の図47(a)と同様の図である。
【図48】 図48は、更なるカードインタフェースシステムアーキテクチャの概略ブロック図である。
【図49】 図49は、カードとアプリケーションとの関係を示す概略ブロック図である。
【図50】 図50は、アプリケーションとサービスグループとの関係を示す図である。
【図51A】、
【図51B】、
【図51C】 図51Aから図51Cは、図48のアーキテクチャ内の多様なカード配列を示す図である。
【図52】 図52は、図48のアーキテクチャに対するスマートカードに格納される制御テンプレートデータを示す図である。
【図53A】、
【図53B】、
【図53C】、
【図53D】、
【図53E】 図53Aから図53Eは、マルチカードアプリケーション構造の一例を示す図である。
【図54】 図54は、図53Aから図53Eの目的を達成するための代替のアプローチを示す図である。
【図55】 図55は、マルチアプリケーション方法の有向グラフ表現を示す図である。
【図56(a)】、
【図56(b)】 図56は、アプリケーションを開始する方法を示す図である。
【図57】 図57は、図11のカードヘッダに続く1つ以上のオブジェクト構造を示す図である。
【図58】 図58は、図8のディレクトリサービスにより実行されるプロセスの概要を示すフローチャートである。
Claims (23)
- 受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するユーザインタフェースカードに対応したサービスをユーザに提供するサービス提供装置であって、
前記カード読取り装置より、前記印の1つを特定する第1のデータを受信し、
ここで、前記第1のデータは前記インターフェースカードのメモリから読み込んだデータである;
前記インターフェースカードを特定する第2のデータを受信する中央処理装置を有し、
ここで、前記第2のデータは、前記インターフェースカードの挿入時から、前記カード読取り装置の前記レセプタクルから前記インターフェースカードを取り除くまでの間、前記カード読取り装置に対する操作が行われる度に、前記サービス提供装置に転送される;
前記サービス提供装置は、前記第1のデータを、前記第2のデータによって特定されるサービスに対する指示情報としてサービスを提供するように構成される
ことを特徴とするサービス提供装置。 - 前記第1のデータは、前記カード読取り装置に設けられた実質的に透明な感圧膜上のユーザ押下位置を定義しする情報データであり、
ここで、前記感圧膜は前記インターフェースカードに重なるように構成される;
前記情報データは前記カードが前記読取り装置へと挿入されていないときは、ユーザによる前記感圧膜の押下に応じて前記読取り装置から受信される
ことを特徴とする請求項1記載のサービス提供装置。 - 前記中央処理装置は、現在のフロントアプリケーションに関連づけられたデータとは異なる前記第2のデータを受信した場合に応じて、前記フロントアプリケーションから、複数の更なるアプリケーションのうちの1つへの変更を制御するように構成されることを特徴とする請求項1記載のサービス提供装置。
- 前記中央処理装置は、不正なカードが前記カード読取り装置へと挿入されるとユーザに警告する請求項1記載のサービス提供装置。
- 前記中央処理装置は、前記データにより定義されるメモリアドレスを利用して前記メモリアドレスに格納されるデータをアクセスするように構成される請求項1記載のサービス提供装置。
- 前記メモリアドレスはURLであることを特徴とする請求項5記載のサービス提供装置。
- 受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードに対応したサービスをユーザに提供するサービス提供装置であって、
前記カード読取り装置より、前記印の1つを特定する第1のデータを受信する手段と、
ここで、前記第1のデータは、前記カードのメモリから読み込まれる;
前記インターフェースカードを識別する第2のデータを受信する手段とを備え、
ここで、前記第2のデータは、前記インターフェースカードの挿入時から、前記カード読取り装置の前記レセプタクルから前記インターフェースカードを取り除くまでの間、前記カード読取り装置に対する操作が行われる度に、前記カード読取り装置から前記サービス提供装置に転送される;
前記サービス提供装置は、前記第1のデータを、前記第2のデータによって特定されるサービスに対する指示情報としてサービスを提供する
ことを特徴とするサービス提供装置。 - 受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードに対応したサービスをユーザに提供する方法であって、
前記カード読取り装置から、前記印の1つを特定する第1のデータを受信する工程と、
ここで、前記第1のデータは、前記カードのメモリから読み込まれる;
前記カード読取り装置から、前記インターフェースカードを特定する第2のデータを受信する工程と、
ここで、前記第2のデータは、前記インターフェースカードの挿入時から、前記カード読取り装置の前記レセプタクルから前記インターフェースカードを取り除くまでの間、前記カード読取り装置に対する操作が行われる度に、前記カード読取り装置から前記サービス提供装置に転送される;
前記第1のデータを、前記第2のデータによって特定されるサービスに対する指示情報としてサービスを提供する工程と
を備えることを特徴とする方法。 - コンピュータが読み込み実行することで、受け入れのためのレセプタクルを有するカード読取り装置へと挿入されるように構成され、印が形成された基板を具備するインタフェースカードに対応したサービスをユーザに提供するサービス提供装置として機能させるプログラムであって、
前記カード読取り装置から、前記印の1つを特定する第1のデータを受信する工程と、
ここで、前記第1のデータは、前記カードのメモリから読み込まれる;
前記カード読取り装置から、前記インターフェースカードを特定する第2のデータを受信する工程と、
ここで、前記第2のデータは、前記インターフェースカードの挿入時から、前記カード読取り装置の前記レセプタクルから前記インターフェースカードを取り除くまでの間、前記カード読取り装置に対する操作が行われる度に、前記カード読取り装置から前記サービス提供装置に転送される;
前記第1のデータを、前記第2のデータによって特定されるサービスに対する指示情報としてサービスを提供する工程
として機能させることを特徴とするプログラム。 - 前記サービス提供装置中のコンピュータ可読な媒体に格納されることを特徴とする請求項9記載のプログラム。
- 前記第2のデータは、1つの前記印の選択に応じて前記サービス提供装置に送信されることを特徴とする請求項1に記載のサービス提供装置。
- 前記第2のデータは、1つの前記印の選択が解除されることに応じて前記サービス提供装置に送信されることを特徴とする請求項1に記載のサービス提供装置。
- 前記第2のデータは、前記インターフェースカードが前記カード読取り装置に挿入されることに応じて、前記サービス提供装置に送信されることを特徴とする請求項1に記載のサービス提供装置。
- 前記第2のデータは、前記インターフェースカードが前記カード読取り装置から取り除かれることに応じて、前記サービス提供装置に送信されることを特徴とする請求項1に記載のサービス提供装置。
- 前記第2のデータは、前記選択位置の移動に応じて前記サービス提供装置に送信されることを特徴とする請求項1に記載のサービス提供装置。
- 前記第2のデータはサービス識別子であることを特徴とする請求項1に記載のサービス提供装置。
- 前記識別子は、アプリケーションによる利用のため、ベンダーによって設定されることを特徴とする請求項16に記載のサービス提供装置。
- 前記サービス識別子は、中央機関によってベンダーに割り当てられることを特徴とする請求項17に記載のサービス提供装置。
- 第2のデータは、擬似乱数であることを特徴とする請求項1に記載のサービス提供装置。
- 第2のデータは、前記カードが前記レセプタクルに挿入する毎に増加することを特徴とする請求項1に記載のサービス提供装置。
- 第2のデータは、前記インターフェースカードにメモリ無いに格納されていることを特徴とする請求項1に記載のサービス提供装置。
- 前記サービス提供装置はセットトップボックスであることを特徴とする請求項1に記載のサービス提供装置。
- 前記サービス提供装置はパーソナルコンピュータであることを特徴とする請求項1に記載のサービス提供装置。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AUPR0073A AUPR007300A0 (en) | 2000-09-12 | 2000-09-12 | User customisable interface architecture |
AUPR5593A AUPR559301A0 (en) | 2001-06-08 | 2001-06-08 | System for card-based service access |
PCT/AU2001/001145 WO2002023411A1 (en) | 2000-09-12 | 2001-09-12 | System for card-based service access |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2004508784A JP2004508784A (ja) | 2004-03-18 |
JP2004508784A5 JP2004508784A5 (ja) | 2005-12-22 |
JP3817518B2 true JP3817518B2 (ja) | 2006-09-06 |
Family
ID=25646439
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002527988A Expired - Fee Related JP3817518B2 (ja) | 2000-09-12 | 2001-09-12 | カード利用サービスへのアクセスのためのシステム |
JP2002527906A Expired - Fee Related JP4478386B2 (ja) | 2000-09-12 | 2001-09-12 | インタフェースカード及びインタフェースカードを使用してサービスを提供する方法 |
JP2002527905A Pending JP2004518185A (ja) | 2000-09-12 | 2001-09-12 | サービスへのアクセスのためのカード読取り装置 |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002527906A Expired - Fee Related JP4478386B2 (ja) | 2000-09-12 | 2001-09-12 | インタフェースカード及びインタフェースカードを使用してサービスを提供する方法 |
JP2002527905A Pending JP2004518185A (ja) | 2000-09-12 | 2001-09-12 | サービスへのアクセスのためのカード読取り装置 |
Country Status (5)
Country | Link |
---|---|
US (3) | US7159763B2 (ja) |
EP (3) | EP1325403A4 (ja) |
JP (3) | JP3817518B2 (ja) |
CA (3) | CA2421601A1 (ja) |
WO (3) | WO2002023411A1 (ja) |
Families Citing this family (97)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7239226B2 (en) | 2001-07-10 | 2007-07-03 | American Express Travel Related Services Company, Inc. | System and method for payment using radio frequency identification in contact and contactless transactions |
US7889052B2 (en) | 2001-07-10 | 2011-02-15 | Xatra Fund Mx, Llc | Authorizing payment subsequent to RF transactions |
AU2001243473A1 (en) | 2000-03-07 | 2001-09-17 | American Express Travel Related Services Company, Inc. | System for facilitating a transaction |
US7181416B2 (en) * | 2000-06-08 | 2007-02-20 | Blackstone Corporation | Multi-function transaction processing system |
US7546947B1 (en) | 2000-06-08 | 2009-06-16 | Arias Luis A | Multi-function transaction processing system |
US20040111322A1 (en) * | 2000-06-08 | 2004-06-10 | Arias Luis A. | Multi-function transaction processing system |
WO2002023411A1 (en) * | 2000-09-12 | 2002-03-21 | Canon Kabushiki Kaisha | System for card-based service access |
US7650314B1 (en) | 2001-05-25 | 2010-01-19 | American Express Travel Related Services Company, Inc. | System and method for securing a recurrent billing transaction |
US7360689B2 (en) | 2001-07-10 | 2008-04-22 | American Express Travel Related Services Company, Inc. | Method and system for proffering multiple biometrics for use with a FOB |
US7746215B1 (en) | 2001-07-10 | 2010-06-29 | Fred Bishop | RF transactions using a wireless reader grid |
US8001054B1 (en) | 2001-07-10 | 2011-08-16 | American Express Travel Related Services Company, Inc. | System and method for generating an unpredictable number using a seeded algorithm |
US20040236699A1 (en) | 2001-07-10 | 2004-11-25 | American Express Travel Related Services Company, Inc. | Method and system for hand geometry recognition biometrics on a fob |
US7303120B2 (en) | 2001-07-10 | 2007-12-04 | American Express Travel Related Services Company, Inc. | System for biometric security using a FOB |
US7249112B2 (en) | 2002-07-09 | 2007-07-24 | American Express Travel Related Services Company, Inc. | System and method for assigning a funding source for a radio frequency identification device |
US9024719B1 (en) | 2001-07-10 | 2015-05-05 | Xatra Fund Mx, Llc | RF transaction system and method for storing user personal data |
US8548927B2 (en) | 2001-07-10 | 2013-10-01 | Xatra Fund Mx, Llc | Biometric registration for facilitating an RF transaction |
US8294552B2 (en) | 2001-07-10 | 2012-10-23 | Xatra Fund Mx, Llc | Facial scan biometrics on a payment device |
US8279042B2 (en) | 2001-07-10 | 2012-10-02 | Xatra Fund Mx, Llc | Iris scan biometrics on a payment device |
US9031880B2 (en) | 2001-07-10 | 2015-05-12 | Iii Holdings 1, Llc | Systems and methods for non-traditional payment using biometric data |
US7668750B2 (en) | 2001-07-10 | 2010-02-23 | David S Bonalle | Securing RF transactions using a transactions counter |
US7735725B1 (en) | 2001-07-10 | 2010-06-15 | Fred Bishop | Processing an RF transaction using a routing number |
US9454752B2 (en) | 2001-07-10 | 2016-09-27 | Chartoleaux Kg Limited Liability Company | Reload protocol at a transaction processing entity |
US9778794B2 (en) | 2001-11-02 | 2017-10-03 | Neonode Inc. | Light-based touch screen |
US8095879B2 (en) * | 2002-12-10 | 2012-01-10 | Neonode Inc. | User interface for mobile handheld computer unit |
US9052777B2 (en) | 2001-11-02 | 2015-06-09 | Neonode Inc. | Optical elements with alternating reflective lens facets |
US8674966B2 (en) | 2001-11-02 | 2014-03-18 | Neonode Inc. | ASIC controller for light-based touch screen |
IL151573A (en) * | 2002-09-02 | 2008-11-26 | Douglas York Malawsky | A device for transferring data from an external carrier to an electronic handheld device |
US20060116167A1 (en) * | 2002-09-02 | 2006-06-01 | Roni Raviv | Selectable functionality communication system and methodologies |
US6805287B2 (en) | 2002-09-12 | 2004-10-19 | American Express Travel Related Services Company, Inc. | System and method for converting a stored value card to a credit card |
US20060032911A1 (en) * | 2002-10-07 | 2006-02-16 | Arias Luis A | Prepaid card issuing system |
US8416217B1 (en) | 2002-11-04 | 2013-04-09 | Neonode Inc. | Light-based finger gesture user interface |
US7268667B2 (en) * | 2003-05-09 | 2007-09-11 | American Express Travel Related Services Company, Inc. | Systems and methods for providing a RF transaction device operable to store multiple distinct accounts |
US7506002B2 (en) * | 2003-09-29 | 2009-03-17 | Sap Ag | Efficient deletion of archived data |
US7418717B1 (en) * | 2003-10-03 | 2008-08-26 | Sun Microsystems, Inc. | Smart card framework |
GB0327694D0 (en) * | 2003-11-28 | 2003-12-31 | Ibm | A system for distributed communications |
FR2864296B1 (fr) * | 2003-12-17 | 2006-04-28 | Gemplus Card Int | Immunite aux variations de ressources limitees, fournies a un objet a interface duale |
US7886032B1 (en) * | 2003-12-23 | 2011-02-08 | Google Inc. | Content retrieval from sites that use session identifiers |
US7191288B2 (en) | 2004-02-24 | 2007-03-13 | Sun Microsystems, Inc. | Method and apparatus for providing an application on a smart card |
US7374099B2 (en) * | 2004-02-24 | 2008-05-20 | Sun Microsystems, Inc. | Method and apparatus for processing an application identifier from a smart card |
US7140549B2 (en) * | 2004-02-24 | 2006-11-28 | Sun Microsystems, Inc. | Method and apparatus for selecting a desired application on a smart card |
US7165727B2 (en) * | 2004-02-24 | 2007-01-23 | Sun Microsystems, Inc. | Method and apparatus for installing an application onto a smart card |
JP2005346511A (ja) * | 2004-06-04 | 2005-12-15 | Oki Electric Ind Co Ltd | 金融機関における受付受取分離システム |
US7318550B2 (en) | 2004-07-01 | 2008-01-15 | American Express Travel Related Services Company, Inc. | Biometric safeguard method for use with a smartcard |
US7232073B1 (en) | 2004-12-21 | 2007-06-19 | Sun Microsystems, Inc. | Smart card with multiple applications |
US7587502B2 (en) * | 2005-05-13 | 2009-09-08 | Yahoo! Inc. | Enabling rent/buy redirection in invitation to an online service |
US20060258461A1 (en) * | 2005-05-13 | 2006-11-16 | Yahoo! Inc. | Detecting interaction with an online service |
US8014505B2 (en) * | 2005-09-02 | 2011-09-06 | Locus Telecommunications, Inc. | Point-of-sale electronic PIN distribution system |
EP2711889A3 (en) * | 2005-09-28 | 2014-04-30 | Visa International Service Association | Device, system and method for reducing an interaction time for a contactless transaction |
WO2007109924A1 (en) * | 2006-03-29 | 2007-10-04 | Intel Corporation | Apparatus and method for a mobile personal computer system (mpc) with a built-in scanner |
US7992203B2 (en) * | 2006-05-24 | 2011-08-02 | Red Hat, Inc. | Methods and systems for secure shared smartcard access |
US8098829B2 (en) | 2006-06-06 | 2012-01-17 | Red Hat, Inc. | Methods and systems for secure key delivery |
US8364952B2 (en) | 2006-06-06 | 2013-01-29 | Red Hat, Inc. | Methods and system for a key recovery plan |
US8180741B2 (en) | 2006-06-06 | 2012-05-15 | Red Hat, Inc. | Methods and systems for providing data objects on a token |
US8332637B2 (en) | 2006-06-06 | 2012-12-11 | Red Hat, Inc. | Methods and systems for nonce generation in a token |
US7822209B2 (en) | 2006-06-06 | 2010-10-26 | Red Hat, Inc. | Methods and systems for key recovery for a token |
US8495380B2 (en) | 2006-06-06 | 2013-07-23 | Red Hat, Inc. | Methods and systems for server-side key generation |
US8707024B2 (en) | 2006-06-07 | 2014-04-22 | Red Hat, Inc. | Methods and systems for managing identity management security domains |
US8099765B2 (en) | 2006-06-07 | 2012-01-17 | Red Hat, Inc. | Methods and systems for remote password reset using an authentication credential managed by a third party |
US8412927B2 (en) | 2006-06-07 | 2013-04-02 | Red Hat, Inc. | Profile framework for token processing system |
US8589695B2 (en) | 2006-06-07 | 2013-11-19 | Red Hat, Inc. | Methods and systems for entropy collection for server-side key generation |
US9769158B2 (en) * | 2006-06-07 | 2017-09-19 | Red Hat, Inc. | Guided enrollment and login for token users |
US20080040767A1 (en) * | 2006-08-11 | 2008-02-14 | Sbc Knowledge Ventures, L.P. | System and method of providing a set-top box application |
US8787566B2 (en) | 2006-08-23 | 2014-07-22 | Red Hat, Inc. | Strong encryption |
US8806219B2 (en) | 2006-08-23 | 2014-08-12 | Red Hat, Inc. | Time-based function back-off |
US8356342B2 (en) | 2006-08-31 | 2013-01-15 | Red Hat, Inc. | Method and system for issuing a kill sequence for a token |
US8074265B2 (en) * | 2006-08-31 | 2011-12-06 | Red Hat, Inc. | Methods and systems for verifying a location factor associated with a token |
US9038154B2 (en) * | 2006-08-31 | 2015-05-19 | Red Hat, Inc. | Token Registration |
US8977844B2 (en) | 2006-08-31 | 2015-03-10 | Red Hat, Inc. | Smartcard formation with authentication keys |
EP2067383A1 (en) * | 2006-09-12 | 2009-06-10 | Koninklijke Philips Electronics N.V. | System for selecting and controlling light settings |
US8693690B2 (en) | 2006-12-04 | 2014-04-08 | Red Hat, Inc. | Organizing an extensible table for storing cryptographic objects |
US8813243B2 (en) | 2007-02-02 | 2014-08-19 | Red Hat, Inc. | Reducing a size of a security-related data object stored on a token |
US8832453B2 (en) | 2007-02-28 | 2014-09-09 | Red Hat, Inc. | Token recycling |
US8639940B2 (en) * | 2007-02-28 | 2014-01-28 | Red Hat, Inc. | Methods and systems for assigning roles on a token |
US9081948B2 (en) | 2007-03-13 | 2015-07-14 | Red Hat, Inc. | Configurable smartcard |
JP4618317B2 (ja) * | 2008-04-10 | 2011-01-26 | コニカミノルタビジネステクノロジーズ株式会社 | 画像形成装置 |
KR100968255B1 (ko) * | 2008-07-01 | 2010-07-06 | 이병진 | 터치스크린을 이용한 접촉카드 인식 시스템 및 인식 방법 |
US20110281652A1 (en) * | 2009-02-02 | 2011-11-17 | Marc Laverdiere | Touch Music Player |
US8775023B2 (en) | 2009-02-15 | 2014-07-08 | Neanode Inc. | Light-based touch controls on a steering wheel and dashboard |
KR101642933B1 (ko) * | 2009-12-04 | 2016-07-27 | 삼성전자주식회사 | 디지털 리빙네트워크 얼라이언스 네트워크에서 전력소모를 줄이기 위한 방법 및 장치 |
US9092093B2 (en) | 2012-11-27 | 2015-07-28 | Neonode Inc. | Steering wheel user interface |
US12032817B2 (en) | 2012-11-27 | 2024-07-09 | Neonode Inc. | Vehicle user interface |
EP2806348A1 (en) * | 2013-05-22 | 2014-11-26 | TP Vision Holding B.V. | System and method for navigating in a graphical user interface, using navigation buttons |
US9324065B2 (en) | 2014-06-11 | 2016-04-26 | Square, Inc. | Determining languages for a multilingual interface |
US10496975B2 (en) | 2014-07-23 | 2019-12-03 | Square, Inc. | Point of sale system with secure and unsecure modes |
US9342227B2 (en) * | 2014-09-02 | 2016-05-17 | Microsoft Technology Licensing, Llc | Semantic card view |
US11080674B1 (en) | 2014-09-19 | 2021-08-03 | Square, Inc. | Point of sale system |
US11080675B1 (en) | 2015-09-08 | 2021-08-03 | Square, Inc. | Point-of-sale system having a secure touch mode |
US10609552B2 (en) * | 2016-08-05 | 2020-03-31 | Tendyron Corporation | System and method for data communication protection |
US10679201B2 (en) | 2016-11-04 | 2020-06-09 | Nxp B.V. | Personal point of sale (pPOS) device that provides for card present E-commerce transaction |
TWI602459B (zh) * | 2017-02-22 | 2017-10-11 | 芯光飛股份有限公司 | 通訊系統及物聯網系統 |
JP6736757B2 (ja) * | 2017-02-28 | 2020-08-05 | 株式会社ソニー・インタラクティブエンタテインメント | 情報処理装置およびソフトウェア処理方法 |
US11514418B2 (en) | 2017-03-19 | 2022-11-29 | Nxp B.V. | Personal point of sale (pPOS) device with a local and/or remote payment kernel that provides for card present e-commerce transaction |
US11620623B2 (en) | 2018-05-31 | 2023-04-04 | Nxp B.V. | Merchant transaction mirroring for personal point of sale (pPOS) for card present e-commerce and in vehicle transaction |
CN113165515B (zh) | 2018-11-28 | 2021-11-02 | 内奥诺德公司 | 驾驶员用户界面传感器 |
KR20210030106A (ko) * | 2019-09-09 | 2021-03-17 | 엘지전자 주식회사 | 서버 |
JP2023544332A (ja) | 2020-09-30 | 2023-10-23 | ネオノード インコーポレイテッド | 光学式タッチセンサ |
CN112712625A (zh) * | 2020-12-31 | 2021-04-27 | 重庆文理学院 | 一种智慧社区管理***及方法 |
Family Cites Families (59)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US25278A (en) * | 1859-08-30 | Improvement in tinmen s machines | ||
US17616A (en) * | 1857-06-23 | Means for reducing topsails | ||
US54647A (en) * | 1866-05-08 | Improvement in arranging vats for tanning | ||
US20745A (en) * | 1858-06-29 | And john sharp | ||
US23953A (en) * | 1859-05-10 | John selser | ||
JPS5968072A (ja) | 1982-10-13 | 1984-04-17 | Sharp Corp | 機能変換用小形電子機器 |
JPS59123986A (ja) | 1982-12-29 | 1984-07-17 | Sharp Corp | 多目的小型携帯用電子機器及び情報カード |
US4731926A (en) | 1985-02-19 | 1988-03-22 | Drug Delivery Systems Inc. | Method of manufacturing disposable and/or replenishable transdermal drug applicators |
JPS62107360A (ja) | 1985-11-05 | 1987-05-18 | Sharp Corp | メモリ−カ−ド電子機器 |
JPS62137689A (ja) | 1985-12-11 | 1987-06-20 | Sharp Corp | Icカ−ド用情報処理装置 |
DE3885877D1 (de) | 1988-02-02 | 1994-01-05 | Landis & Gyr Business Support | Programmierbares Steuer- oder Regelgerät. |
EP0346685B1 (en) | 1988-05-31 | 1994-04-20 | Sharp Kabushiki Kaisha | An ambulatory electrocardiographic apparatus |
US5015830A (en) | 1988-07-04 | 1991-05-14 | Sharp Kabushiki Kaisha | Electronic card reading device |
US5235328A (en) | 1988-08-23 | 1993-08-10 | Sony Corporation | Remote command apparatus |
JPH0322259A (ja) * | 1989-03-22 | 1991-01-30 | Seiko Epson Corp | 小型データ表示・再生装置 |
JP2521242Y2 (ja) | 1989-11-16 | 1996-12-25 | 株式会社コパル | カメラ用シャッター装置 |
US5583539A (en) * | 1990-01-10 | 1996-12-10 | Sharp Kabushiki Kaisha | Item selection signal input apparatus that reduces the processing load of a host computer |
JPH0488547A (ja) | 1990-07-31 | 1992-03-23 | Sharp Corp | 小型電子機器 |
JP3085471B2 (ja) | 1991-01-24 | 2000-09-11 | ソニー株式会社 | リモートコマンダ |
JPH05189624A (ja) | 1991-04-09 | 1993-07-30 | Ricoh Co Ltd | 電子機器装置 |
US5235456A (en) * | 1991-05-10 | 1993-08-10 | Amoco Corporation | Tunable pulsed single longitudinal mode optical parametric oscillator |
GB2255934B (en) * | 1991-05-13 | 1994-10-05 | Richelt George Williams | Credit/bank card security system |
JP2749018B2 (ja) | 1991-05-28 | 1998-05-13 | シャープ株式会社 | メモリカード |
US5949492A (en) | 1995-11-22 | 1999-09-07 | Mankovitz; Roy J. | Apparatus and methods for accessing information relating to radio television programs |
US5880769A (en) * | 1994-01-19 | 1999-03-09 | Smarttv Co. | Interactive smart card system for integrating the provision of remote and local services |
FR2721730B1 (fr) | 1994-06-22 | 1996-08-23 | Clifford Holding Ltd | Boîtier de commande à clavier coopérant avec une carte à mémoire qui rend le boîtier et le clavier fonctionnels. |
JPH0944576A (ja) | 1995-08-02 | 1997-02-14 | Hitachi Ltd | 電子財布貸付システム |
EP0816989A3 (en) | 1996-07-06 | 1999-04-07 | Saitek Limited | Configurable computer input device |
SE515527C2 (sv) | 1996-11-19 | 2001-08-20 | Viking Sewing Machines Ab | Datastyrd symaskin |
JPH10155188A (ja) | 1996-11-20 | 1998-06-09 | Toshiba Corp | リモコン信号伝送装置及びリモコン信号伝送方法 |
JPH10214314A (ja) | 1997-01-30 | 1998-08-11 | Toshiba Corp | Icカード用携帯端末装置およびその制御方法 |
US6145740A (en) * | 1997-04-29 | 2000-11-14 | Diebold, Incorporated | Electronic purse card value system |
JPH1198566A (ja) | 1997-09-19 | 1999-04-09 | Sony Corp | 無線通信システムおよび無線通信方法、ならびに無線送信装置、無線受信装置、および無線伝送装置 |
FR2771205B1 (fr) | 1997-11-20 | 2000-01-21 | Gemplus Card Int | Procede, carte a puce et terminaux pour effectuer des transactions a travers un reseau de telecommunication |
US6068183A (en) * | 1998-04-17 | 2000-05-30 | Viztec Inc. | Chip card system |
US6201977B1 (en) | 1998-04-24 | 2001-03-13 | Micron Technology, Inc. | Power-saving mode for portable communication devices |
US6424845B1 (en) * | 1998-06-19 | 2002-07-23 | Ncr Corporation | Portable communication device |
JP2000020439A (ja) | 1998-07-07 | 2000-01-21 | Nippon Telegr & Teleph Corp <Ntt> | 情報記憶型カードを用いたインターネットアクセス装置およびシステムおよびその方法 |
US5973475A (en) | 1998-09-04 | 1999-10-26 | Ic-Tv Interactive Cyber Television Inc. | Remote smart battery |
EP0992953A3 (en) | 1998-10-08 | 2004-06-02 | Canon Kabushiki Kaisha | A user programmable smart card interface system |
AU742974B2 (en) | 1998-10-08 | 2002-01-17 | Canon Kabushiki Kaisha | A user programmable smart card interface system |
US6591229B1 (en) | 1998-10-09 | 2003-07-08 | Schlumberger Industries, Sa | Metrology device with programmable smart card |
FR2785070B1 (fr) | 1998-10-26 | 2001-01-12 | Xiring | Systeme d'affichage comprenant une carte a microcircuit et un lecteur |
US6249290B1 (en) | 1998-12-14 | 2001-06-19 | Sony Corporation | Object oriented zooming graphical user interface |
JP2000224161A (ja) | 1999-02-01 | 2000-08-11 | Ntt Data Corp | カード認証式サービス運用システム |
JP3490921B2 (ja) | 1999-02-12 | 2004-01-26 | 株式会社エヌ・ティ・ティ・データ | プリペイドカードシステム、中継装置及び読書装置 |
US6764001B1 (en) | 2000-05-30 | 2004-07-20 | Sony Corporation | Electronic money system and transaction method using the same |
US6804786B1 (en) | 1999-09-10 | 2004-10-12 | Canon Kabushiki Kaisha | User customizable secure access token and multiple level portable interface |
US6871782B2 (en) | 1999-10-08 | 2005-03-29 | Canon Kabushiki Kaisha | User programmable smart card interface system having an arbitrary mapping |
AUPQ585100A0 (en) | 2000-02-25 | 2000-03-16 | Canon Kabushiki Kaisha | Customisable filter interface |
JP3071329U (ja) | 2000-02-28 | 2000-08-29 | 船井電機株式会社 | ホームページ表示システムおよびデータ送信機 |
US6824045B2 (en) | 2000-04-20 | 2004-11-30 | Canon Kabushiki Kaisha | Method and system for using multiple smartcards in a reader |
JP3946931B2 (ja) * | 2000-04-25 | 2007-07-18 | 船井電機株式会社 | タブレット式情報端末装置及びそれを用いたホームページ閲覧システム |
AUPQ730600A0 (en) | 2000-05-04 | 2000-05-25 | Canon Kabushiki Kaisha | A method for self-programming smart cards |
US6466804B1 (en) | 2000-08-25 | 2002-10-15 | Motorola, Inc. | Method and apparatus for remote multiple access to subscriber identity module |
AUPQ983500A0 (en) | 2000-08-31 | 2000-09-28 | Canon Kabushiki Kaisha | Hyperlink access system |
WO2002023411A1 (en) | 2000-09-12 | 2002-03-21 | Canon Kabushiki Kaisha | System for card-based service access |
AUPR559201A0 (en) | 2001-06-08 | 2001-07-12 | Canon Kabushiki Kaisha | Card reading device for service access |
AUPR559101A0 (en) | 2001-06-08 | 2001-07-12 | Canon Kabushiki Kaisha | Card for service access |
-
2001
- 2001-09-12 WO PCT/AU2001/001145 patent/WO2002023411A1/en active IP Right Grant
- 2001-09-12 US US10/363,581 patent/US7159763B2/en not_active Expired - Fee Related
- 2001-09-12 CA CA002421601A patent/CA2421601A1/en not_active Abandoned
- 2001-09-12 EP EP01966821A patent/EP1325403A4/en not_active Withdrawn
- 2001-09-12 JP JP2002527988A patent/JP3817518B2/ja not_active Expired - Fee Related
- 2001-09-12 WO PCT/AU2001/001143 patent/WO2002023321A1/en active IP Right Grant
- 2001-09-12 WO PCT/AU2001/001142 patent/WO2002023320A1/en active IP Right Grant
- 2001-09-12 EP EP01966822A patent/EP1325404A4/en not_active Withdrawn
- 2001-09-12 JP JP2002527906A patent/JP4478386B2/ja not_active Expired - Fee Related
- 2001-09-12 US US10/363,217 patent/US6978933B2/en not_active Expired - Fee Related
- 2001-09-12 EP EP01964761A patent/EP1325441A4/en not_active Withdrawn
- 2001-09-12 CA CA002421634A patent/CA2421634C/en not_active Expired - Fee Related
- 2001-09-12 JP JP2002527905A patent/JP2004518185A/ja active Pending
- 2001-09-12 CA CA002421603A patent/CA2421603C/en not_active Expired - Fee Related
- 2001-09-12 US US10/363,679 patent/US7455227B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
CA2421603A1 (en) | 2002-03-21 |
CA2421603C (en) | 2007-03-06 |
EP1325441A4 (en) | 2007-08-15 |
US20030191713A1 (en) | 2003-10-09 |
US7159763B2 (en) | 2007-01-09 |
US20040024735A1 (en) | 2004-02-05 |
WO2002023320A9 (en) | 2003-05-08 |
US20040122753A1 (en) | 2004-06-24 |
US6978933B2 (en) | 2005-12-27 |
JP2004508783A (ja) | 2004-03-18 |
WO2002023321A1 (en) | 2002-03-21 |
CA2421601A1 (en) | 2002-03-21 |
JP2004508784A (ja) | 2004-03-18 |
US7455227B2 (en) | 2008-11-25 |
JP4478386B2 (ja) | 2010-06-09 |
EP1325403A4 (en) | 2006-04-19 |
WO2002023320A1 (en) | 2002-03-21 |
JP2004518185A (ja) | 2004-06-17 |
EP1325404A4 (en) | 2006-02-01 |
EP1325403A1 (en) | 2003-07-09 |
EP1325441A1 (en) | 2003-07-09 |
CA2421634A1 (en) | 2002-03-21 |
WO2002023411A1 (en) | 2002-03-21 |
CA2421634C (en) | 2009-06-23 |
EP1325404A1 (en) | 2003-07-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3817518B2 (ja) | カード利用サービスへのアクセスのためのシステム | |
US6827263B2 (en) | Card for service access | |
US7156302B2 (en) | Card reading device for service access | |
US6915957B2 (en) | User interface for interaction with smart card applications | |
EP1148438A2 (en) | A method and system for using multiple smartcards in a reader | |
US20030212896A1 (en) | User interface for accessing files in a smartcard file | |
US7236978B2 (en) | Configurable input buffer | |
AU2001287367B2 (en) | Card reading device for service access | |
AU2001285607B2 (en) | System for card-based service access | |
AU2001287368B2 (en) | Card for service access | |
US6971583B2 (en) | Method of securely preserving volatile data while powering down a smart card | |
AU775732B2 (en) | Card for service access | |
AU776304B2 (en) | Card reading device for service access | |
AU2001287368A1 (en) | Card for service access | |
AU2001285607A1 (en) | System for card-based service access | |
AU2001287367A1 (en) | Card reading device for service access | |
AU2002318850B2 (en) | A Method of Securely Preserving Volatile Data While Powering Down a Smart Card | |
AU2002318849B2 (en) | A Configurable Input Buffer | |
JP2002297290A (ja) | リモコン装置およびリモコン装置における情報処理方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050407 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051219 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060215 |
|
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: 20060605 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060612 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090616 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100616 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110616 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120616 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130616 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |