WO2013133058A1 - 通信装置、制御方法、及びプログラム - Google Patents

通信装置、制御方法、及びプログラム Download PDF

Info

Publication number
WO2013133058A1
WO2013133058A1 PCT/JP2013/054671 JP2013054671W WO2013133058A1 WO 2013133058 A1 WO2013133058 A1 WO 2013133058A1 JP 2013054671 W JP2013054671 W JP 2013054671W WO 2013133058 A1 WO2013133058 A1 WO 2013133058A1
Authority
WO
WIPO (PCT)
Prior art keywords
target
application
command
priority
targets
Prior art date
Application number
PCT/JP2013/054671
Other languages
English (en)
French (fr)
Inventor
鈴木 孝
典弘 市丸
勝幸 照山
Original Assignee
フェリカネットワークス株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by フェリカネットワークス株式会社 filed Critical フェリカネットワークス株式会社
Priority to CN201380011796.4A priority Critical patent/CN104428796B/zh
Priority to JP2014503767A priority patent/JP6162683B2/ja
Priority to IN7294DEN2014 priority patent/IN2014DN07294A/en
Priority to EP17187515.6A priority patent/EP3276537B1/en
Priority to KR1020147024308A priority patent/KR102040348B1/ko
Priority to US14/382,070 priority patent/US9237409B2/en
Priority to EP13758604.6A priority patent/EP2824611B1/en
Publication of WO2013133058A1 publication Critical patent/WO2013133058A1/ja
Priority to US14/955,582 priority patent/US9444519B2/en
Priority to US15/220,020 priority patent/US10305547B2/en
Priority to US16/380,432 priority patent/US11088724B2/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04BTRANSMISSION
    • H04B5/00Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/72Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for local intradevice communication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327Short range or proximity payments by means of M-devices
    • G06Q20/3278RFID or NFC payments by means of M-devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/50Allocation or scheduling criteria for wireless resources
    • H04W72/56Allocation or scheduling criteria for wireless resources based on priority criteria
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W76/00Connection management
    • H04W76/10Connection setup
    • H04W76/14Direct-mode setup
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04MTELEPHONIC COMMUNICATION
    • H04M2250/00Details of telephonic subscriber devices
    • H04M2250/04Details of telephonic subscriber devices including near field communication means, e.g. RFID
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/60Subscription-based services using application servers or record carriers, e.g. SIM application toolkits

Definitions

  • the present technology relates to a communication device, a control method, and a program, and more particularly, to a communication device, a control method, and a program that can reliably select a desired target.
  • NFC Near Field Communication
  • targets a plurality of communication objects
  • NFC device As an NFC device, it has multiple secure elements as targets and a front end that is used in common with those secure elements and communicates with external devices such as readers in close proximity. On the other hand, one that assigns different time slots for communication has already been proposed (see, for example, Patent Document 1).
  • CRF Contactless Front End
  • the front end returns one polling response in response to polling from the reader side, so the reader performs processing for the target corresponding to the polling response. Therefore, the single response method has the merit that it can be installed without providing a special circuit, but compared with the multi-response method, the target correct answer rate (the probability that the reader can respond to the response from the target desired by the reader) "Means") will be low.
  • the front end returns multiple polling responses in response to polling from the reader side. Therefore, if the reader supports multiple response reception, the reader is selected from multiple polling responses. Processing for the target corresponding to the desired polling response is performed. For this reason, the multi-response method requires a special circuit to send back multiple responses at the same time, which complicates the mounting surface, but increases the target correct answer rate compared to the single-response method. be able to.
  • the present technology has been made in view of such a situation, and the reader can reliably select a desired target corresponding to the above-mentioned operation specifications of the reader and without mounting a special circuit on the front end. It is something that can be done.
  • a communication device selects a target to be communicated with an external device from the plurality of targets, each of which executes a predetermined process, and the external device.
  • a front end for performing near field communication wherein the plurality of targets include a P2P (Peer ⁇ ⁇ ⁇ ⁇ to Peer) application, and the front end receives a first target for receiving the confirmed target candidate received from the external device. 1 command is transmitted to the plurality of targets, and the P2P application is selected as the highest priority target in selecting the confirmed target candidate, and the confirmed target candidate is selected and received from the external device.
  • P2P Peer ⁇ ⁇ ⁇ ⁇ to Peer
  • the determined target candidates are When the P2P application is selected as the fixed target candidate when the P2P application is not selected as the fixed target when the P2P application is selected as the fixed target candidate, the P2P application in the selection of the fixed target candidate is selected. Reduce the priority of.
  • the front end When the front end receives the first command from the external device, the front end broadcasts the first command to the plurality of targets.
  • the other targets excluding the P2P application include at least one or both of a secure element and a UICC (Universal Integrated Circuit Card), and the front end includes the P2P application.
  • the priority is changed to the next priority of one or both of the secure element and the UICC.
  • the front end changes the priority so that the secure element, the UICC, and the P2P application are in this order.
  • the front end changes the priority so that the secure element, the P2P application, and the UICC are in this order.
  • the other target further includes a predetermined application conforming to a predetermined standard, and the front end is in the order of the secure element, the UICC, the predetermined application, and the P2P application. Change the priority.
  • the front end changes the priority of the P2P application to the lowest priority.
  • the front end changes the priority according to the operation sequence of the external device.
  • the front end When the priority of the P2P application is changed, the front end returns the priority of the P2P application to the highest priority when a predetermined period has elapsed.
  • the front end releases the confirmed target from the communication target of the external device based on a predetermined target release condition.
  • the front end releases the confirmed target from the communication target of the external device when there is a response from one of the targets when the first command is broadcasted to the plurality of targets.
  • the front end selects the confirmed target candidate as the confirmed target when the identification information included in the second command matches the identification information of the confirmed target candidate.
  • control method and program according to one aspect of the present technology are a control method and program corresponding to the communication device according to one aspect of the present technology described above.
  • a fixed target that is a communication target of the external device is selected from a plurality of targets that each execute predetermined processing, and the proximity to the external device is selected. Communication takes place.
  • a first command for selecting a confirmed target candidate received from an external device is transmitted to a plurality of targets, and a P2P application is selected as a target with the highest priority in selecting a confirmed target candidate.
  • the confirmed target candidate is selected as the confirmed target, and the P2P application is selected as the confirmed target candidate.
  • the P2P application is not selected as the final target when selected, the priority of the P2P application in selecting the final target is lowered.
  • FIG. 3 is a diagram illustrating a configuration example of an NFC device.
  • the NFC device 11 is configured as a device such as a mobile phone, an IC card, a portable information terminal, or a personal computer, for example.
  • the NFC device 11 communicates with an external device such as the NFC reader 12 using a carrier wave having a frequency of 13.56 MHz in, for example, an ISM (Industry Science Medical) band within a distance of several tens of centimeters (including the case of contact). I do.
  • a carrier wave having a frequency of 13.56 MHz in, for example, an ISM (Industry Science Medical) band within a distance of several tens of centimeters (including the case of contact). I do.
  • the NFC device 11 includes a CLF 31, an ESE 32, a DH 33, and a UICC 34.
  • Each of the CLF 31 and the target ESE 32, DH 33, and UICC 34 are connected by wire and can communicate with each other.
  • a CLF (Contactless Front End) 31 is connected to an antenna provided in the NFC device 11 and performs near field communication with the NFC reader 12.
  • the CLF 31 selects a target desired by the NFC reader 12 in accordance with a command transmitted from the NFC reader 12, and controls the communication with the NFC reader 12.
  • the CLF 31 has a built-in memory 31A, and stores various data in the memory 31A as necessary.
  • the ESE (Embedded Secure Element) 32 is a secure element that is a core part including IC chip security, and implements a security function in, for example, electronic payments, electronic tickets, and NFC applications for entrance / exit management.
  • the DH 33 controls the operation of each part of the NFC device 11.
  • the DH 33 executes the P2P application 41 or the T3T application 42.
  • the P2P application 41 is a P2P (Peer to Peer) application program.
  • the T3T application 42 is an application program for emulation of T3T (Type 3 Tag) defined by the NFC standard.
  • One or a plurality of P2P applications 41 and T3T applications 42 can be executed.
  • the UICC (Universal Integrated Circuit Card) 34 is composed of, for example, a SIM (Subscriber Identity Module) card.
  • the UICC 34 realizes, for example, an electronic payment function by executing an NFC application program.
  • the ESE 32, UICC 34, P2P application 41, and T3T application 42 are targets to be communicated with the NFC reader 12, and each performs predetermined processing.
  • the target includes devices such as ESE 32 and UICC 34 and application programs such as P2P application 41 and T3T application 42.
  • the target may include an application program executed by the ESE 32 or the UICC 34.
  • the NFC device 11 is configured as described above.
  • FIG. 4 is a diagram showing a detailed configuration example of the CLF 31 of FIG.
  • the CLF 31 includes a packet reception processing unit 101, a routing state management unit 102, a priority management unit 103, and a wireless communication control unit 104.
  • the packet reception processing unit 101 performs processing related to the received packet transmitted from the NFC reader 12.
  • the routing state management unit 102 manages the state transition of routing performed in the CLF 31.
  • the routing state includes a neutral state and a select state, which will be described later.
  • the priority management unit 103 manages the priority of the response from the target to the polling command. Note that the information on the priority is held in the memory 31A and is read out as needed.
  • the wireless communication control unit 104 performs processing for controlling near field communication performed with the NFC reader 12.
  • the CLF 31 is configured as described above.
  • Routing performed in the CLF 31 is realized by a routing state machine and a process of processing received packets in each state.
  • the state machine includes two states, a neutral state (NEUTRAL) and a selected state (SELECTED).
  • the neutral state means a state where the target is not fixed
  • the selected state means a state where the target is fixed.
  • the received packet from the NFC reader 12 is analyzed, and processing for determining the target is performed according to the analysis result.
  • the routing state transitions from the neutral state to the selected state.
  • the selected state includes a P2P selected state (P2P SELECTED) and a T3T selected state (T3T SELECTED) depending on the protocol.
  • P2P selected state means a state where the P2P application 41 is selected.
  • T3T selected state means a state in which ESE 32, UICC 34, T3T application 42, or the like other than the P2P application 41 is selected. Further, when a predetermined release condition occurs and the confirmed target is released, the routing state transitions from the selected state to the neutral state.
  • the confirmed target is selected from the targets existing in the NFC device 11 based on a predetermined check condition for input information such as a command code stored in the received packet from the NFC reader 12 and a protocol of the received packet. Is determined by the CLF 31 as a single communication target. The CLF 31 distributes the received packet to the selected final target until the final target is canceled or the final target is changed.
  • FIG. 6 is a diagram showing the state transition of the routing state machine.
  • the routing state transitions from the neutral state to the P2P selected state.
  • the T3T application 42 or the like is selected as a final target in the neutral state, the routing state transitions from the neutral state to the T3T selected state.
  • a SENSF_REQ command is received or when an RF (Radio-Frequency) signal is turned off, the routing state remains in the neutral state.
  • the routing state is P2P Transition from the selected state to the neutral state. If a command other than the above is received in the P2P selected state, the routing state remains in the P2P selected state.
  • the RLS_REQ command and the DSL_REQ command are commands for instructing the end of the P2P communication transaction.
  • the PSL_REQ command is a command for instructing a change in the communication state of P2P communication.
  • the RF_DEACTIVATE_CMD command is a command for instructing termination in conformity with a predetermined standard.
  • the routing state transitions from the T3T selected state to the neutral state.
  • the routing state remains in the T3T selected state.
  • the routing state transitions from the T3T selected state to the P2P selected state.
  • the CLF 31 transits to the routing state of any one of the neutral state, the P2P selected state, and the T3T selected state, and performs a received packet processing process according to the state.
  • the packet reception processing process is classified into a processing process when a polling command is received and a processing process when a command other than the polling command is received.
  • FIG. 7 is a diagram illustrating a processing process when a polling command is received.
  • the CLF 31 When the CLF 31 receives a SENSF_REQ command from the NFC reader 12, the CLF 31 broadcasts the command to a plurality of targets.
  • the CLF 31 broadcasts a SENSF_REQ command as a polling command for searching for candidates that can be targets.
  • the SENSF_REQ command is a command for searching for a candidate for a definite target and acquiring information about the target.
  • NFCID2 that can uniquely identify the target is used.
  • the SENSF_REQ command for the P2P application 41 and the T3T application 42 is processed in the CLF 31 without being transmitted to the DH 33.
  • a target to which the SENSF_REQ command is not actually transmitted is referred to as a logical target.
  • a target to which the SENSF_REQ command is actually transmitted such as ESE 32 and UICC 34, is distinguished as a physical target.
  • the SENSF_REQ command will be described as being broadcasted not only to the physical target but also to the logical target.
  • the CENS 31 when the CLF 31 receives a SENSF_REQ command from the NFC reader 12, the CENS 31 sends the SENSF_REQ command to the P2P application 41L and the T3T application 42L that are logical targets and the ESE 32 that is a physical target. And broadcast to the UICC 34.
  • each target When a SENSF_REQ command is transmitted from the CLF 31, each target responds with a SENSF_RES command according to the SENSF_REQ command, as shown in FIG. Then, the CLF 31 selects a confirmed target candidate to which a response is returned from the targets that have responded according to the priority for the response. The CLF 31 returns SENSF_RES from the selected confirmed target candidate to the NFC reader 12 according to the single response method.
  • the CLF 31 prioritizes the P2P application 41 (P2P application 41L), the ESE 32, the UICC 34, and the T3T application 42 (T3T application 42L). Accordingly, the response of the P2P application 41 having the highest priority among those responses is selected and returned to the NFC reader 12.
  • the CLF 31 may be multiple responses to the SENSF_REQ command from the CLF 31 or no response at all. For example, when only one target has responded to the SENSF_RES command, the CLF 31 returns a SENSF_RES command from the target to the NFC reader 12. If there is no target that has responded to the SENSF_RES command, the CLF 31 does not send a reply to the NFC reader 12. In this case, the CLF 31 maintains the current routing state.
  • the SENSF_REQ command is basically broadcasted to all targets, but may not be sent depending on the target status.
  • FIG. 10 is a diagram illustrating a processing process when a command other than the polling command is received.
  • the CLF 31 When the CLF 31 receives a command other than SENSF_REQ from the NFC reader 12, the CLF 31 transmits the command to a specific target. That is, since commands other than SENSF_REQ are transmitted to a specific target after the NFC reader 12 specifies a desired target, the packet storing the command includes identification information of the specific target. It is. Accordingly, the CLF 31 selects any of the P2P application 41, the T3T application 42, the ESE 32, or the UICC 34 according to the target identification information, and transmits a command.
  • the processing process differs between when a polling command is received and when a command other than the polling command is received.
  • FIG. 11 is a diagram showing an outline of the process of the received packet in the neutral state.
  • command code routing There are three types of routing methods performed in the received packet processing process in the neutral state: command code routing, protocol routing, and technology routing.
  • Command code routing is a routing method in which a command from the NFC reader 12 is constantly monitored, and when a specific command is received, a received packet is sent to a target associated with the command. is there.
  • Protocol routing is a routing method in which a received packet is determined on a protocol basis, and the received packet is sent to a target corresponding to the determination result.
  • protocol routing for example, it is determined whether the protocol of the received packet is a P2P protocol or a T3T protocol.
  • P2P protocol discrimination result routing according to the P2P protocol discrimination result
  • T3T protocol discrimination result routing according to the T3T protocol discrimination result.
  • Technology routing is a routing method in which a received packet is sent to a target specified in advance when the received packet does not belong to any protocol.
  • technology routing for example, when the P2P or T3T protocol is disabled in an implementation, NFC-F packets are sent to the first target, NFC-B packets are sent to the second target, etc. By determining in advance, the received packet can be sent to the corresponding target.
  • ⁇ P2P protocol routing and T3T protocol routing are performed when the final target is not selected in command code routing.
  • a definite target is selected by these protocol routings, a received packet is sent to the definite target.
  • technology routing is performed. In technology routing, since the transmission destination of the received packet is determined, the received packet is sent to the target as the transmission destination.
  • command code routing is performed to realize a specific function in a specific operation, and therefore may not be implemented depending on the operation.
  • the CLF 31 when receiving a command other than SENSF_REQ, the CLF 31 starts from protocol routing without performing command code routing.
  • the CLF 31 performs technology routing.
  • FIG. 12 shows the details of the processing of each routing shown in FIG.
  • command code routing first, the command code of the received packet is checked (S11). If the check condition of S11 is satisfied, NFCID2 of the received packet is compared with NFCID2 of all targets (S12). If NFCID2 matches in S12, it is checked whether a predetermined target is registered in a predetermined routing table (S13). Then, when the check condition of S13 is satisfied, the target is selected as the final target. For example, if the DH 33 is registered as a T3T protocol routing target in the routing table, communication with the DH 33 is possible, so the T3T application 42 is selected as the final target.
  • P2P protocol routing it is checked whether the received command is a P2P command (S21). If the check condition of S21 is satisfied, a predetermined routing table is checked (S22). If the check condition of S22 is satisfied, it is further checked whether the command can respond as a P2P protocol (S23). If the check condition in S23 is satisfied, the P2P application 41 is selected as the final target. As a result, the routing state transitions from the neutral state to the P2P select state.
  • the priority of the response to the SENSF_REQ command (SENSF_RES command) is higher in the order of the P2P application 41, the ESE32, the UICC 34, and the T3T application 42 in the initial state. Therefore, in response to the SENSF_REQ command, after selecting the P2P application 41 as a final target candidate and responding to the SENSF_RES command of the P2P application 41, a transaction is not established unless a predetermined command is sent to the P2P application 41. End up. Therefore, in protocol routing, when a predetermined command for the P2P application 41 cannot be received (“No” in S21), the priority of the response is changed (S31), and the priority of the P2P application 41 is lowered.
  • the CLF 31 changes the priority in the order of ESE 32, UICC 34, T3T application 42, and P2P application 41.
  • the CLF 31 selects the ESE 32 having the highest priority as a final target candidate according to the changed priority, and sends a SENSF_RES command from each target.
  • the response of the ESE 32 is returned to the NFC reader 12.
  • priority change may be performed as a subsequent process when the check condition of S32 described later is not satisfied.
  • the NFCID2 stored in the received packet is compared with the NFCID2 of the target other than the P2P application 41, that is, the T3T application 42, the ESE32, and the UICC 34 (S32). If NFCID2 matches in S32, it is checked whether a predetermined target is registered in a predetermined routing table (S33). Then, when the check condition of S33 is satisfied, the target is selected as the final target. As a result, the routing state transitions from the neutral state to the T3T selected state.
  • a predetermined routing table is checked (S41).
  • the target is selected as the final target.
  • a transition is made from the neutral state to the T3T selected state.
  • the received packet is evaluated, and the final target is selected according to the evaluation result.
  • the routing state transitions from the neutral state to the P2P selected state or the T3T selected state.
  • the priority of the response is given. The degree is changed, and the priority of the P2P application 41 is lowered.
  • FIG. 13 is a diagram showing an outline of a process for processing a received packet in the T3T selected state.
  • the routing method performed in the received packet processing process in the T3T selected state is command code routing and P2P protocol routing.
  • P2P protocol routing is performed when the final target is not selected by command code routing. That is, as shown in the state transition diagram (FIG. 6) described above, since the routing state may transition from the T3T selected state to the P2P selected state, the P2P protocol routing is performed even in the T3T selected state.
  • the routing state transitions from the T3T selected state to the P2P selected state.
  • the P2P application 41 is not selected as the final target, the final target does not change from the current target, and the routing state does not change from the T3T selected state.
  • FIG. 14 shows the details of the processing of each routing shown in FIG.
  • command code routing and P2P protocol routing are performed in the same manner as in FIG. However, if the check conditions of S21, S22, and S23 in FIG. 14 are not satisfied, the protocol routing ends and the confirmed target and the routing state do not change, so the received packet is sent to the current target. In the processing process of FIG. 14, the priority of the response described above is not changed.
  • FIG. 15 is a diagram showing a received packet processing process in the P2P selected state.
  • the CLF 31 transmits all the received packets from the NFC reader 12 to the P2P application 41.
  • the received packet is not evaluated, and the received packet is always transmitted to the P2P application 41 that is the final target.
  • 16 and 17 show the operations of the CLF 31, the ESE 32, and the UICC 34 in response to the command from the NFC reader 12. Further, the P2P application 41L and the T3T application 42L, which are logical targets, are processed in the CLF 31. Here, it is assumed that an application program desired by the NFC reader 12 exists in the ESE 32.
  • SENSF_RES Priority order shown on the right side of the figure indicates the state of the target order in response priority.
  • Normal order means the arrangement order of the P2P application 41 having the highest priority.
  • P2P deprioritised means the arrangement order of the states in which the priority of the P2P application 41 is lowered.
  • P2P_RSP_FLG is a flag that is set when the P2P application 41 responds to the SENSF_RES command.
  • P2P_RSP_FLG is cleared when a SENSF_RES command other than the P2P application 41 responds or when the routing state returns to the neutral state.
  • RoutingRoState indicates the routing state described above, and is in a neutral state, a P2P selected state, or a T3T selected state.
  • the CLF 31 receives the SENSF_REQ command and broadcasts it to each target.
  • the broadcast-transmitted SENSF_REQ command is received by the ESE 32 and the UICC 34, respectively, and the response is returned to the CLF 31. Further, the CLF 31 performs processing related to the P2P application 41L and the T3T application 42L in response to the SENSF_REQ command.
  • the CLF 31 selects the P2P application 41 as a final target candidate and returns a SENSF_RES command including the NFCID2 of the P2P application 41 to the NFC reader 12. Then, in response to the SENSF_RES command from the CLF 31, the NFC reader 12 transmits a Request / System / code command including the NFCID2 of the P2P application 41.
  • the CLF 31 sends a Request System code command from the NFC reader 12 to the ESE 32, but cannot send a response because the command has been sent to the wrong target. As a result, the NFC reader 12 cannot obtain a response, and in this case, the transaction has failed (“FAIL” in the figure).
  • the command set for Ad-hoc communication is a command used in P2P communication defined by the NFC standard.
  • the command set for Ad-hoc communication is a command for ad hoc communication compliant with a predetermined standard.
  • Get Container Issue Information is a command for obtaining information related to an IC chip conforming to a predetermined standard.
  • the CLF 31 changes the priority of the response from the target in the order of the ESE 32, UICC 34, T3T application 42, P2P application 41, and lowers the priority of the P2P application 41.
  • the next transaction other than the P2P application 41 is established.
  • the CLF 31 changes the priority only for a predetermined period, for example, for 5 to 10 seconds, and restores the priority after the period, so that the priority of the P2P application 41 becomes the highest.
  • a period from “Timer start” in FIG. 16 to “Timer expire” in FIG. 17 is a period for changing the priority.
  • the NFC reader 12 turns off the RF signal and then turns it on again. Then, the NFC reader 12 transmits a SENSF_REQ command again.
  • the CLF 31 receives the SENSF_REQ command from the NFC reader 12 and broadcasts it to each target.
  • the ESE 32 and the UICC 34 each return a SENSF_RES command.
  • the CLF 31 selects the ESE 32 as a candidate for a final target and returns a SENSF_RES command including the NFCID2 of the ESE 32 to the NFC reader 12. Then, since the Request System code command including the NFCID2 of the ESE 32 is transmitted from the NFC reader 12, the CLF 31 transmits the command to the ESE 32. At this time, the CLF 31 selects the ESE 32 that has been selected as the confirmed target candidate as the confirmed target. Also, “Routing ⁇ State ”transits from the neutral state to the T3T selected state.
  • ESE 32 Since the Request System Code command includes NFCID2 of ESE 32, ESE 32 returns a Request System code response command in response to the command.
  • the Request System code response command is transmitted to the NFC reader 12 via the CLF 31.
  • This Request System code response command includes “FE00” as the SC of ESE32.
  • the NFC reader 12 transmits a SENSF_REQ command using the SC acquired by the command in response to the Request System Code response command.
  • the CLF 31 receives the SENSF_REQ command from the NFC reader 12 and broadcasts it to each target. However, since the UICC 34 does not support the service with the SC of “FE00”, the SENSF_RES command is returned only from the ESE 32. Become. The CLF 31 returns the SENSF_RES command from the ESE 32 to the NFC reader 12.
  • the NFC reader 12 transmits a Request service command including the NFCID2 of the ESE32 to the ESE32.
  • the CLF 31 transmits a Request Service command from the NFC reader 12 to the ESE 32.
  • the ESE 32 returns a Request Service response command in response to the Request Service command from the CLF 31.
  • the CLF 31 returns a Request Service response command from the ESE 32 to the NFC reader 12.
  • the transaction for the ESE 32 having the highest priority at that time can be established by changing the priority of the response from the target. If a transaction for the ESE 32 is not established, the establishment of the transaction is attempted in the order of the UICC 34 and the T3T application 42 having the next highest priority.
  • the CLF 31 When the end time of the predetermined period has elapsed, the CLF 31 returns the priority of the response to the initial state so that the priority of the P2P application 41 becomes the highest. Thereby, for example, when performing near field communication with other NFC readers thereafter, an attempt is made to establish a transaction for the P2P application 41 having the highest priority.
  • the SC of the polling parameter included in the SENSF_REQ command first sent from the NFC reader 12 is “FFFF”, even though the target other than the P2P application 41 is the communication target, and the RC When (Request Code) is other than “1”, that is, communication may be started with the same polling parameters as P2P communication by the first command of a transaction.
  • the CLF 31 cannot determine from the command whether the response of the P2P application 41 is returned or whether the response of a target other than the P2P application 41 is returned. Therefore, if a command other than a predetermined command such as ATR_REQ is received after the SENSF_RES command of the P2P application 41 is responded to the SENSF_REQ command, the transaction is not established.
  • the priority of the response to the SENSF_REQ command is changed for a predetermined period so that the next transaction is established.
  • the target other than the P2P application 41 can be sequentially determined as a final target candidate. It becomes possible to select a target reliably. As a result, communication performed between the NFC reader 12 and the target can be quickly established.
  • the CLF 31 extracts the NFCID2 stored in the SENSF_RES command packet from the ESE 32 and the UICC 34 when the SENSF_RES command is responded.
  • FIG. 18 shows the storage position of NFCID2 in the packet of the SENSF_RES command.
  • the CLF 31 holds one NFCID2 of each of the ESE 32 and the UICC 34 in the memory 31A in association with the target.
  • the CLF 31 extracts NFCID2 every time there is a response to the SENSF_REQ command, and updates the correspondence information held in the memory 31A.
  • NFCID2 of the P2P application 41 and the T3T application 42 for example, identification information compliant with a predetermined standard is stored in the memory 31A in advance.
  • the CLF 31 extracts NFCID2 included in the SENSF_RES command from the ESE 32 and the UICC 34, and holds it in the memory 31A.
  • NFCID2_ese_0 is extracted as the NFCID2 of the ESE 32
  • NFCID2_uicc_0 is extracted as the NFCID2 of the UICC 34 and held in the memory 31A.
  • the CLF 31 broadcasts the SENSF_REQ command and receives the response only from the ESE 32.
  • the CLF 31 extracts “NFCID2_ese_1” as NFCID2 included in the SENSF_RES command from the ESE 32, and stores it in the memory 31A.
  • the CLF 31 updates the value of NFCID2 held in the memory 31A every time the SENSF_RES command is received.
  • the CLF 31 when the CLF 31 receives a specific command code and forcibly changes the target, the CLF 31 replaces the NFCID2 for communication with the NFC reader 12 and the NFCID2 for communication with the target. I need to communicate.
  • the CLF 31 when the CLF 31 receives a Get Container Issue Information command, it is necessary to use the NFCID2 of the ESE32 when forcibly changing the target to the ESE32. Communicate. In addition, when responding to the NFC reader 12, the CLF 31 responds after replacing again with NFCID2 included in the command received from the NFC reader 12.
  • the CLF 31 when the CLF 31 forcibly changes the target to DH33 when the Propose Ad-hoc Mode command is received, the CLF 31 communicates with the T3T application 42 after replacing the NFCID2 of the T3T application 42 of the DH33. .
  • communication with the NFC reader 12 when communication with the NFC reader 12 is performed, communication is performed using the NFCID2 before replacement.
  • the CLF 31 extracts NFCID2 included in the SENSF_RES command and stores it in the memory 31A. Then, the CLF 31 returns a SENSF_RES command including NFCID2 of the P2P application 41 according to the priority.
  • the CLF 31 replaces the NFCID2 included in the command with the one of the ESE32 from the P2P application 41, and then transmits to the ESE32. Then, since the response to the command is transmitted from the ESE 32, the CLF 31 transmits the NFC reader 2 to the NFC reader 12 after replacing the NFCID 2 included in the response command with that of the P2P application 41 from the ESE 32.
  • the destination of the command designated by the NFC reader 12 can be forcibly changed.
  • Such a replacement process is a necessary process, for example, when the above command code routing is performed.
  • the CLF 31 releases the final target based on a predetermined target release condition.
  • This release condition includes a trigger triggered by the user's operation to terminate the application program being executed, and a cancel condition based on external factors such as the disappearance of the RF signal.
  • the CLF 31 broadcasts a SENSF_REQ command from the NFC reader 12 and releases the confirmed target when a response to the SENSF_RES command is received. In this case, the routing state transitions to the neutral state.
  • the CORE_RESET_CMD command is a command for instructing a reset that conforms to a predetermined standard.
  • step S101 the packet reception processing unit 101 determines whether a command is received from the NFC reader 12. If it is determined in step S101 that a command has been received, the process proceeds to step S102.
  • step S102 the packet reception processing unit 101 determines whether or not the received command is a SENSF_REQ command. If it is determined in step S102 that the command is a SENSF_REQ command, the process proceeds to step S103.
  • step S103 the packet reception processing unit 101 broadcasts a SENSF_REQ command to each target.
  • step S104 the packet reception processing unit 101 receives a SENSF_RES command returned from the target that has received the SENSF_REQ command.
  • step S105 the packet reception processing unit 101 selects a confirmed target candidate to which a response is returned from the responded targets according to the priority of the response.
  • the priority of response is the highest priority in the P2P application 41 in the initial state.
  • step S106 the packet reception processing unit 101 transmits a SENSF_RES command from the confirmed target candidate selected in step S105 to the NFC reader 12.
  • the NFC reader 12 receives the SENSF_RES command from the NFC device 11 and performs processing according to the command.
  • step S102 determines whether the received command is a command other than the SENSF_REQ command. If it is determined in step S102 that the received command is a command other than the SENSF_REQ command, the process proceeds to step S107.
  • step S107 the packet reception processing unit 101 determines whether or not the current routing state is a neutral state. When it is determined in step S107 that the current routing state is the neutral state, the process proceeds to step S108.
  • step S108 the packet reception processing unit 101 processes the received packet in the neutral state.
  • step S131 the packet reception processing unit 101 processes the received packet in the neutral state.
  • the received packet is evaluated by command code routing, protocol routing, and technology routing, and a final target is selected according to the evaluation result. Is done.
  • the routing state management unit 102 changes the routing state from the current neutral state to the P2P selected state or the T3T selected state.
  • step S132 the packet reception processing unit 101 determines whether a response of the SENSF_RES command of the P2P application 41 is made as a response immediately before to the NFC reader 12. If it is determined in step S132 that a response to the SENSF_RES command of the P2P application 41 has been made immediately before, the process proceeds to step S133.
  • step S133 the packet reception processing unit 101 determines whether or not the P2P application 41 is selected as the final target by the process in step S131. If it is determined in step S133 that the P2P application 41 has not been selected as the final target, the process proceeds to step S134.
  • step S134 the priority management unit 103 changes the priority. That is, in this case, the command other than the command for the P2P application 41 is received from the NFC reader 12 even though the response of the SENSF_RES command of the P2P application 41 selected as the confirmed target candidate is received. A degree change is made. For example, the priority management unit 103 lowers the priority of the P2P application 41 that has the highest priority in the initial state, and changes the priority in the order of the ESE 32, UICC 34, T3T application 42, and P2P application 41. In this case, the priority of the P2P application 41 is the lowest priority among the targets.
  • the priority order after the change is not limited to the above order, but can be rearranged in another order.
  • the priority management unit 103 when the target includes the ESE 32, the UICC 34, and the P2P application 41, when the P2P application 41 is not selected as the final target, the priority management unit 103 is in the order of the ESE 32, the UICC 34, and the P2P application 41.
  • the priority can be changed. In this case, the priority management unit 103 may change the priority so that ESE 32, P2P application 41, and UICC 34 are in this order.
  • the priority management unit 103 sets the priority of the P2P application 41 to the next priority of either the ESE 32 or the UICC 34. change. That is, the target includes at least one or both of the ESE 32 and the UICC 34, and the priority management unit 103 sets the priority of the P2P application 41 when the P2P application 41 is not selected as the final target. Change to the next priority of either or both of ESE 32 and UICC 34.
  • the priority management unit 103 may change the response priority according to the operation sequence of the NFC reader 12.
  • the priority order after the change is arbitrarily set according to, for example, the type of target and the form of operation, and in principle, the priority of the P2P application 41 having the highest priority is set. It will be rearranged so that the degree is low.
  • step S132 If it is determined in step S132 that the SENSF_RES command of the P2P application 41 has not been responded immediately before, steps S133 and S134 are skipped. If it is determined in step S133 that the P2P application 41 has been selected as the final target, step S134 is skipped.
  • step S134 When the process in step S134 is completed or skipped, the process returns to step S108 in FIG. 22, and the subsequent processes are performed.
  • step S107 If it is determined in step S107 that the current routing state is not the neutral state, the process proceeds to step S109.
  • step S109 the packet reception processing unit 101 determines whether or not the current routing state is the T3T selected state. If it is determined in step S109 that the current routing state is the T3T selected state, the process proceeds to step S110.
  • step S110 the packet reception processing unit 101 performs reception packet processing in the T3T selected state.
  • the received packet is evaluated by the command code routing and the P2P protocol routing, and the final target is selected according to the evaluation result.
  • step S109 determines whether the current routing state is the T3T selected state, that is, the P2P selected state. If it is determined in step S109 that the current routing state is not the T3T selected state, that is, the P2P selected state, the process proceeds to step S111.
  • step S111 the packet reception processing unit 101 performs reception packet processing in the P2P selected state.
  • the received packet is not evaluated, and the received packet is always transmitted to the P2P application 41.
  • step S101 If it is determined in step S101 that a command has not been received, or if the processing of steps S108, S110, and S111 is completed, the process proceeds to step S112.
  • step S112 the priority management unit 103 determines whether or not the response priority has been changed in step S134 of FIG. If it is determined in step S112 that the priority has been changed, the process proceeds to step S113.
  • step S113 the priority management unit 103 determines whether or not a predetermined period has elapsed. If it is determined in step S113 that the predetermined period has elapsed, the process proceeds to step S114.
  • step S114 the priority management unit 103 returns the priority of the response to the initial state and changes the priority of the P2P application 41 so as to be the highest.
  • step S112 If it is determined in step S112 that the priority has not been changed, if it is determined in step S113 that the predetermined period has not elapsed, or if the process in step S114 is completed, the process proceeds to step S101. Return to, and the subsequent processing is repeated.
  • the command response processing has been described above.
  • a received packet processing process corresponding to the routing state is performed.
  • the received packet is evaluated, and the P2P application 41 is not selected as the final target even though the SENSF_RES command of the P2P application 41 is responded.
  • the priority of the response is changed, and the priority of the P2P application 41 is lowered.
  • the series of processes described above can be executed by hardware or software.
  • a program constituting the software is installed in the computer.
  • the computer includes, for example, a general-purpose personal computer capable of executing various functions by installing a computer incorporated in dedicated hardware and various programs.
  • FIG. 24 is a block diagram showing an example of the hardware configuration of a computer that executes the above-described series of processing by a program.
  • a CPU Central Processing Unit
  • ROM Read Only Memory
  • RAM Random Access Memory
  • An input / output interface 205 is further connected to the bus 204.
  • An input unit 206, an output unit 207, a storage unit 208, a communication unit 209, and a drive 210 are connected to the input / output interface 205.
  • the input unit 206 includes a keyboard, a mouse, a microphone, and the like.
  • the output unit 207 includes a display, a speaker, and the like.
  • the storage unit 208 includes a hard disk, a nonvolatile memory, and the like.
  • the communication unit 209 includes a network interface and the like.
  • the drive 210 drives a removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory.
  • the CPU 201 loads the program stored in the storage unit 208 to the RAM 203 via the input / output interface 205 and the bus 204 and executes the program, as described above. A series of processing is performed.
  • the program executed by the computer 200 can be provided by being recorded in, for example, a removable medium 211 such as a package medium.
  • the program can be provided via a wired or wireless transmission medium such as a local area network, the Internet, or digital satellite broadcasting.
  • the program can be installed in the storage unit 208 via the input / output interface 205 by attaching the removable medium 211 to the drive 210.
  • the program can be received by the communication unit 209 via a wired or wireless transmission medium and installed in the storage unit 208.
  • the program can be installed in the ROM 202 or the storage unit 208 in advance.
  • the program executed by the computer 200 may be a program that is processed in time series in the order described in this specification, or a necessary timing such as in parallel or when a call is made. It may be a program in which processing is performed.
  • processing steps for describing a program for causing the computer 200 to perform various processes do not necessarily have to be processed in time series according to the order described in the flowchart, and may be performed in parallel or individually. (For example, parallel processing or object processing).
  • the program may be processed by one computer, or may be processed in a distributed manner by a plurality of computers. Furthermore, the program may be transferred to a remote computer and executed.
  • the system means a set of a plurality of components (devices, modules (parts), etc.), and it does not matter whether all the components are in the same housing. Accordingly, a plurality of devices housed in separate housings and connected via a network and a single device housing a plurality of modules in one housing are all systems. .
  • the present technology can take a configuration of cloud computing in which one function is shared by a plurality of devices via a network and is jointly processed.
  • each step described in the above-described flowchart can be executed by one device or can be shared by a plurality of devices.
  • the plurality of processes included in the one step can be executed by being shared by a plurality of apparatuses in addition to being executed by one apparatus.
  • this technique can take the following structures.
  • a plurality of targets each performing a predetermined process;
  • the plurality of targets include a P2P (Peer to Peer) application,
  • the front end is Transmitting a first command received from the external device to select a candidate for the final target, to the plurality of targets;
  • the P2P application is set as the highest priority target, and the final target candidate is selected.
  • the candidate for the final target is selected as the final target.
  • the priority of the P2P application in the selection of the confirmed target candidate is lowered.
  • targets excluding the P2P application include at least one or both of a secure element and a UICC (Universal Integrated Circuit Card),
  • the other target further includes a predetermined application conforming to a predetermined standard,
  • the front end returns the priority of the P2P application to the highest priority when a predetermined period has elapsed. (1) Thru
  • a plurality of targets each performing a predetermined process;
  • a control method for a communication device comprising: a front end that selects a final target to be communicated with an external device from the plurality of targets and performs near field communication with the external device,
  • the plurality of targets are: Including an application of P2P (Peer to Peer) received from the external device,
  • the front end is Transmitting a first command for selecting the final target candidates to the plurality of targets;
  • the P2P application is set as the highest priority target, and the final target candidate is selected.
  • the candidate for the final target is selected as the final target.
  • the priority of the P2P application in the selection of the confirmed target candidate is lowered. Control method.
  • a plurality of targets each performing a predetermined process comprising: a front end that selects a target to be communicated with an external device from the plurality of targets including a P2P (Peer to Peer) application and performs near field communication with the external device
  • P2P Peer to Peer
  • the P2P application is set as the highest priority target, and the final target candidate is selected.
  • the candidate for the final target is selected as the final target.
  • the priority of the P2P application in the selection of the confirmed target candidate is lowered.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Near-Field Transmission Systems (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)

Abstract

 本技術は、所望のターゲットを確実に選択することができるようにする通信装置、制御方法、及びプログラムに関する。 CLFは、NFCリーダから受信した確定ターゲットの候補を選択するためのポーリングコマンドをターゲットに送信し、確定ターゲットの候補を選択するにあたりP2Pアプリを最も高い優先度のターゲットとし、確定ターゲットの候補を選択し、NFCリーダから受信したポーリングコマンド以外のコマンドに基づいて、確定ターゲットを選択し、P2Pアプリが確定ターゲットの候補として選択された場合に、P2Pアプリが確定ターゲットに選択されなかったときには、P2Pアプリの優先度を下げるように制御する。本技術は、例えば、NFC規格に対応した通信装置に適用することができる。

Description

通信装置、制御方法、及びプログラム
 本技術は、通信装置、制御方法、及びプログラムに関し、特に、所望のターゲットを確実に選択することができるようにした通信装置、制御方法、及びプログラムに関する。
 無線通信の規格として、NFC(Near Field Communication)が知られている。NFC規格に対応したNFCデバイスでは、端末内に複数の通信対象(以下、ターゲットという)が同時に存在する場合が想定される。
 NFCデバイスとして、ターゲットとしての複数のセキュアエレメントと、それらのセキュアエレメントに共通に使用され、リーダなどの外部装置と近接通信するフロントエンドとを備え、フロントエンドが、起動時に、複数のセキュアエレメントに対して通信のための異なるタイムスロットを割り当てるものが既に提案されている(例えば、特許文献1参照)。
 図1に示すように、NFCの無線通信を行う非接触無線チップ(CLF:Contactless Front End)(以下、フロントエンドともいう)と、リーダ(reader)が近接通信を行う場合、シングルレスポンスとマルチレスポンスの2つの方式がある。
 シングルレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが1つのポーリングレスポンスを返すので、リーダは、そのポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、シングルレスポンス方式では、特別な回路を設けることなく実装できるというメリットがある反面、マルチレスポンス方式と比べてターゲットの正答率(「リーダに対して、リーダが望むターゲットからのレスポンスを応答できる確率」を意味する)が低くなってしまう。
 一方、マルチレスポンス方式では、リーダ側からのポーリングに応じて、フロントエンドが複数のポーリングレスポンスを返すので、リーダは、複数レスポンス受信に対応していれば、複数のポーリングレスポンスの中から選択された所望のポーリングレスポンスに対応するターゲットに対する処理を行う。そのため、マルチレスポンス方式は、一度に複数のレスポンスを返信するための特別な回路をフロントエンドに設ける必要があって実装面が複雑になる反面、シングルレスポンス方式と比べてターゲットの正答率を高くすることができる。
特開2011-49778号公報
 ところで、図2に示すように、フロントエンドがマルチレスポンス方式の機能を有する場合であっても、例えば3つのポーリングレスポンスを返したいときに、2つのタイムスロットしかないと、スロット不足のため、一度にポーリングレスポンスを返信することができなくなる。このように、マルチレスポンス方式では、スロット数が多ければ、ポーリングスロットをすべて返信することが可能となるが、リーダが、TSN=0,1など、小さいTSN(Time Slot Number)によりポーリングしてきた場合に、スロット数が不足してしまい、すべてのポーリングレスポンスを返せなくなるときがある。また、アプリケーションプログラムによっては、電子マネーのアプリケーションプログラムのようにシングルレスポンスを期待するものや、リーダの実装制約により、マルチレスポンスを受信できないものも存在する。
 また、マルチレスポンス方式を利用するためには、特別な回路をフロントエンドに設ける必要があるため、マルチレスポンス方式に対応してない既存のデバイスだと、特別な回路を実装する必要が出てくる。
 さらに、リーダから送られるコマンドによっては、フロントエンドにて、どのターゲットのレスポンスを返信すればよいかを判別できない場合があり、その場合には、リーダが所望とするターゲットを選択できないことになる。
 本技術はこのような状況に鑑みてなされたものであり、上記のリーダの動作仕様に対応し、かつ、フロントエンドに特別な回路を実装することなく、リーダが所望とするターゲットを確実に選択することができるようにするものである。
 本技術の一側面の通信装置は、それぞれが所定の処理を実行する複数のターゲットと、前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドとを備え、前記複数のターゲットは、P2P(Peer to Peer)のアプリケーションを含み、前記フロントエンドは、前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる。
 前記フロントエンドは、前記外部装置から前記第1のコマンドを受信した場合、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信する。
 前記複数のターゲットのうち、前記P2Pのアプリケーションを除く他のターゲットは、セキュアエレメント及びUICC(Universal Integrated Circuit Card)のいずれか一方又は双方を少なくとも含んでおり、前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を、前記セキュアエレメント及び前記UICCのいずれか一方又は双方の次の優先度に変更する。
 前記フロントエンドは、前記セキュアエレメント、前記UICC、前記P2Pのアプリケーションの順となるように前記優先度を変更する。
 前記フロントエンドは、前記セキュアエレメント、前記P2Pのアプリケーション、前記UICCの順となるように前記優先度を変更する。
 前記他のターゲットは、さらに、所定の規格に準拠した所定のアプリケーションを含んでおり、前記フロントエンドは、前記セキュアエレメント、前記UICC、前記所定のアプリケーション、前記P2Pのアプリケーションの順となるように前記優先度を変更する。
 前記フロントエンドは、前記P2Pのアプリケーションの優先度を、最も低い優先度に変更する。
 前記フロントエンドは、前記外部装置の動作シーケンスに応じて、前記優先度を変更する。
 前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を変更した場合に、あらかじめ設定された所定の期間を経過したとき、前記P2Pのアプリケーションの前記優先度を、最も高い優先度に戻す。
 前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する。
 前記フロントエンドは、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信した場合に、いずれかのターゲットからの応答があったとき、前記確定ターゲットを、前記外部装置の通信対象から解除する。
 前記フロントエンドは、前記第2のコマンドに含まれる識別情報と、前記確定ターゲットの候補の識別情報が一致する場合、前記確定ターゲットの候補を、前記確定ターゲットとして選択する。
 本技術の一側面の制御方法及びプログラムは、前述した本技術の一側面の通信装置に対応する制御方法及びプログラムである。
 本技術の一側面の通信装置、制御方法、及びプログラムにおいては、それぞれが所定の処理を実行する複数のターゲットの中から、外部装置の通信対象となる確定ターゲットが選択され、外部装置との近接通信が行われる。また、外部装置から受信した確定ターゲットの候補を選択するための第1のコマンドが、複数のターゲットに送信され、確定ターゲットの候補を選択するにあたりP2Pのアプリケーションが最も高い優先度のターゲットとされ、確定ターゲットの候補が選択され、外部装置から受信した所定のターゲットの識別情報を含む第2のコマンドに基づいて、確定ターゲットの候補が、確定ターゲットとして選択され、P2Pのアプリケーションが確定ターゲットの候補として選択された場合に、P2Pのアプリケーションが確定ターゲットに選択されなかったとき、確定ターゲットの候補の選択におけるP2Pのアプリケーションの優先度が下げられる。
 本技術の一側面によれば、所望のターゲットを確実に選択することができる。
近接通信の方式を説明する図である。 マルチレスポンス方式における応答条件の例を示す図である。 NFCデバイスの構成例を示す図である。 CLFの詳細な構成例を示す図である。 ルーティングのステートマシンの概要を示す図である。 ルーティングのステートマシンの状態遷移を示す図である。 ポーリングコマンドを受信した場合の処理プロセスを示す図である。 SENSF_REQコマンドの処理プロセスを示す図である。 SENSF_RESコマンドの処理プロセスを示す図である。 ポーリングコマンド以外のコマンドを受信した場合の処理プロセスを示す図である。 ニュートラル状態における受信パケットの処理プロセスを示す図である。 ニュートラル状態における受信パケットの処理プロセスを示す図である。 T3Tセレクト状態における受信パケットの処理プロセスを示す図である。 T3Tセレクト状態における受信パケットの処理プロセスを示す図である。 P2Pセレクト状態における受信パケットの処理プロセスを示す図である。 本技術を利用した具体的な運用例を示すシーケンス図である。 本技術を利用した具体的な運用例を示すシーケンス図である。 SENSF_RESコマンドのパケットにてNFCID2の格納位置を示す図である。 NFCID2の抽出及び一時的保持の処理を示すシーケンス図である。 NFCID2のリプレイス処理の概要を示す図である。 NFCID2のリプレイス処理を示すシーケンス図である。 コマンド対応処理を説明するフローチャートである。 ニュートラル状態における受信パケットの処理を説明するフローチャートである。 コンピュータの構成例を示す図である。
 以下、図面を参照しながら本技術の実施の形態について説明する。
[NFCデバイスの構成例]
 図3は、NFCデバイスの構成例を示す図である。
 NFCデバイス11は、例えば、携帯電話機、ICカード、携帯情報端末、又はパーソナルコンピュータなどの装置として構成される。NFCデバイス11は、NFCリーダ12等の外部装置と、例えばISM(Industry Science Medical)バンドの13.56MHzの周波数の搬送波を用いて、数10cm以内(接触している場合も含む)の距離で近接通信を行う。
 NFCデバイス11は、CLF31、ESE32、DH33、及びUICC34から構成される。CLF31と、ターゲットとしてのESE32、DH33、及びUICC34のそれぞれは、有線により接続され、相互に通信可能とされる。
 CLF(Contactless Front End)31は、NFCデバイス11内に設けられたアンテナに接続され、NFCリーダ12と近接通信を行う。CLF31は、NFCリーダ12から送信されてくるコマンドに応じて、NFCリーダ12が所望とするターゲットを選択して、NFCリーダ12との間で通信が行われるように制御する。
 また、CLF31は、メモリ31Aを内蔵しており、必要に応じて各種のデータを、メモリ31Aに記憶する。
 ESE(Embedded Secure Element)32は、ICチップのセキュリティを含めたコア部分となるセキュアエレメントであって、例えば、電子決済や電子乗車券、入退室管理のNFCアプリケーションにおけるセキュリティ機能を実現する。
 DH(Device Host)33は、NFCデバイス11の各部の動作を制御する。また、DH33は、P2Pアプリ41又はT3Tアプリ42を実行する。P2Pアプリ41は、P2P(Peer to Peer)のアプリケーションプログラムである。また、T3Tアプリ42は、NFC規格により規定されているT3T(Type 3 Tag)のエミュレーション用のアプリケーションプログラムである。P2Pアプリ41及びT3Tアプリ42は、それぞれ、1又は複数実行可能とされる。
 UICC(Universal Integrated Circuit Card)34は、例えば、SIM(Subscriber Identity Module)カードから構成される。UICC34は、NFCアプリケーションプログラムを実行することで、例えば、電子決済機能を実現する。
 このように、ESE32、UICC34、P2Pアプリ41、及びT3Tアプリ42は、NFCリーダ12の通信対象となるターゲットであって、それぞれが所定の処理を行う。換言すれば、ターゲットには、ESE32やUICC34などのデバイスと、P2Pアプリ41やT3Tアプリ42などのアプリケーションプログラムが含まれることになる。ただし、ターゲットには、ESE32又はUICC34にて実行されるアプリケーションプログラムが含まれるようにしてもよい。
 NFCデバイス11は、以上のように構成される。
[CLFの詳細な構成例]
 図4は、図3のCLF31の詳細な構成例を示す図である。
 CLF31は、パケット受信処理部101、ルーティング状態管理部102、優先度管理部103、及び無線通信制御部104から構成される。
 パケット受信処理部101は、NFCリーダ12から送信される受信パケットに関する処理を行う。
 ルーティング状態管理部102は、CLF31にて行われるルーティングの状態遷移を管理する。ルーティング状態には、後述するニュートラル状態とセレクト状態がある。
 優先度管理部103は、ポーリングコマンドに対するターゲットからの応答(レスポンス)の優先度を管理する。なお、優先度に関する情報は、メモリ31Aに保持され、必要に応じて適宜読み出される。
 無線通信制御部104は、NFCリーダ12との間で行われる近接通信を制御するための処理を行う。
 CLF31は、以上のように構成される。
[CLFによるルーティングの概要]
 次に、CLF31によるルーティングの概要について説明する。CLF31にて行われるルーティングは、ルーティングのステートマシンと、各ステートにおける受信パケットの処理プロセスによって実現される。
[ルーティングのステートマシン]
 図5に示すように、ステートマシンは、ニュートラル状態(NEUTRAL)と、セレクト状態(SELECTED)の2つの状態で構成される。ニュートラル状態は、ターゲットが確定していない状態を意味し、セレクト状態は、ターゲットが確定している状態を意味する。
 ニュートラル状態では、NFCリーダ12からの受信パケットの解析が行われ、当該解析結果に応じて、ターゲットを確定するための処理が行われる。ターゲットが確定すると、ルーティング状態は、ニュートラル状態からセレクト状態に遷移する。
 セレクト状態では、受信パケットが、ニュートラル状態にて確定された確定ターゲットに自動的に振り分けられる。また、セレクト状態には、プロトコルに応じて、P2Pセレクト状態(P2P SELECTED)と、T3Tセレクト状態(T3T SELECTED)が存在する。P2Pセレクト状態は、P2Pアプリ41が選択されている状態を意味する。T3Tセレクト状態は、P2Pアプリ41以外のESE32、UICC34、又はT3Tアプリ42等が選択されている状態を意味する。また、所定の解除条件が発生して確定ターゲットが解除されると、ルーティング状態は、セレクト状態からニュートラル状態に遷移する。
 確定ターゲットは、NFCリーダ12からの受信パケットに格納されたコマンドコードや受信パケットのプロトコルなどの入力情報に対する所定のチェック条件に基づいて、NFCデバイス11内に存在するターゲットの中から、NFCリーダ12との単一の通信対象として、CLF31により決定されるものである。CLF31は、確定ターゲットが解除されるか、又は確定ターゲットが変更されるまでは、受信パケットを、選択された確定ターゲットに振り分けることになる。
 図6は、ルーティングのステートマシンの状態遷移を示す図である。
 図6において、ニュートラル状態にてP2Pアプリ41が確定ターゲットとして選択されると、ルーティング状態は、ニュートラル状態からP2Pセレクト状態に遷移する。また、ニュートラル状態にてT3Tアプリ42等が確定ターゲットとして選択されると、ルーティング状態は、ニュートラル状態からT3Tセレクト状態に遷移する。また、SENSF_REQコマンドが受信された場合や、RF(Radio Frequency)信号がオフになった場合には、ルーティング状態は、ニュートラル状態に留まる。
 P2Pセレクト状態にて、RF信号がオフになった場合、又はRLS_REQコマンド、DSL_REQコマンド、NFC-Aへの technology changeを伴うPSL_REQコマンド、若しくはRF_DEACTIVATE_CMDコマンドが受信された場合には、ルーティング状態は、P2Pセレクト状態からニュートラル状態に遷移する。また、P2Pセレクト状態にて、上記以外のコマンドが受信された場合には、ルーティング状態は、P2Pセレクト状態に留まる。なお、RLS_REQコマンド,DSL_REQコマンドは、P2P通信のトランザクションの終了を指示するためのコマンドである。PSL_REQコマンドは、P2P通信の通信状態の変更を指示するためのコマンドである。また、RF_DEACTIVATE_CMDコマンドは、所定の規格に準拠した終了を指示するためのコマンドである。
 T3Tセレクト状態にて、RF_DEACTIVATE_CMDコマンドが受信された場合、又はSENSF_REQコマンドが各ターゲットにブロードキャスト送信された後に、その応答が返信された場合には、ルーティング状態は、T3Tセレクト状態からニュートラル状態に遷移する。また、T3Tセレクト状態にて、SENSF_REQコマンドに対する応答が返信されなかった場合やRF信号がオフになった場合などは、ルーティング状態は、T3Tセレクト状態に留まる。さらに、T3Tセレクト状態にて、有効なP2Pのコマンドを受信した場合、ルーティング状態は、T3Tセレクト状態からP2Pセレクト状態に遷移する。
 このように、CLF31は、ニュートラル状態、P2Pセレクト状態、又はT3Tセレクト状態のいずれかのルーティング状態に遷移し、その状態に応じた受信パケットの処理プロセスを行うことになる。
[受信パケットの処理プロセス]
 パケット受信の処理プロセスは、ポーリングコマンドを受信した場合の処理プロセスと、ポーリングコマンド以外のコマンドを受信した場合の処理プロセスに分類される。
(ポーリングコマンドを受信した場合の処理プロセス)
 図7は、ポーリングコマンドを受信した場合の処理プロセスを示す図である。
 CLF31は、NFCリーダ12からSENSF_REQコマンドを受信した場合、当該コマンドを、複数のターゲットにブロードキャスト送信する。
 すなわち、SENSF_REQコマンドを格納するパケットには、ターゲットを特定するための識別情報が含まれていないため、ターゲットを特定するためのプロセスに用いることはできない。従って、CLF31は、ターゲットの対象となり得る候補を探索するためのポーリングコマンドとして、SENSF_REQコマンドを、ブロードキャスト送信する。換言すれば、NFCリーダ12にとって、SENSF_REQコマンドは、確定ターゲットの候補を探索して、当該ターゲットに関する情報を取得するためのコマンドであると言える。
 なお、ターゲットの識別情報としては、例えば、ターゲットを一意に識別可能なNFCID2が用いられる。
 また、P2Pアプリ41及びT3Tアプリ42に対するSENSF_REQコマンドは、DH33には送信されずに、CLF31内で処理される。以下、このような、実際にはSENSF_REQコマンドが送信されないターゲットを、論理ターゲットと称する一方、例えば、ESE32やUICC34のように、SENSF_REQコマンドが実際に送られるターゲットを、物理ターゲットと称して区別する。ただし、論理ターゲットと、物理ターゲットを区別する必要がない場合には、単に、ターゲットと称する。本実施の形態において、SENSF_REQコマンドは、物理ターゲットに対してだけでなく、論理ターゲットにもブロードキャスト送信されるものとして説明する。
 より具体的には、図8に示すように、CLF31は、NFCリーダ12からSENSF_REQコマンドを受信した場合、当該SENSF_REQコマンドを、論理ターゲットであるP2Pアプリ41L及びT3Tアプリ42Lと、物理ターゲットであるESE32及びUICC34にブロードキャスト送信する。
 CLF31からSENSF_REQコマンドが送信されると、図9に示すように、各ターゲットのそれぞれは、SENSF_REQコマンドに応じて、SENSF_RESコマンドを応答することになる。そして、CLF31は、応答があったターゲットの中から、当該応答に対する優先度に従って、応答を返信する確定ターゲットの候補を選択する。CLF31は、シングルレスポンス方式に従い、選択した確定ターゲットの候補からのSENSF_RESを、NFCリーダ12に返信する。
 例えば、CLF31は、P2Pアプリ41L、T3Tアプリ42L、ESE32、及びUICC34から応答があった場合、P2Pアプリ41(P2Pアプリ41L)、ESE32、UICC34、T3Tアプリ42(T3Tアプリ42L)の順の優先度に従って、それらの応答のうち、最も高い優先度のP2Pアプリ41の応答を選択し、NFCリーダ12に返信する。
 なお、CLF31からのSENSF_REQコマンドに対しては、複数応答がある場合や応答が全くない場合もある。例えば、SENSF_RESコマンドの応答をしてきたターゲットが1つだけであった場合、CLF31は、当該ターゲットからのSENSF_RESコマンドを、NFCリーダ12に返信する。また、SENSF_RESコマンドの応答をしてきたターゲットが1つもなかった場合、CLF31は、NFCリーダ12に対する返信を行わないことになる。この場合、CLF31は、現在のルーティングの状態を維持する。
 また、SENSF_REQコマンドは、基本的にすべてのターゲットにブロードキャスト送信されるものであるが、ターゲットの状態などによっては、送信されない場合もある。
(ポーリングコマンド以外のコマンドを受信した場合の処理プロセス)
 図10は、ポーリングコマンド以外のコマンドを受信した場合の処理プロセスを示す図である。
 CLF31は、NFCリーダ12からSENSF_REQ以外のコマンドを受信した場合、当該コマンドを、特定のターゲットに送信する。すなわち、SENSF_REQ以外のコマンドは、NFCリーダ12が所望のターゲットを特定した上で、特定のターゲットに送信されるものであるため、当該コマンドを格納するパケットには、特定のターゲットの識別情報が含まれている。従って、CLF31は、ターゲットの識別情報に応じて、P2Pアプリ41、T3Tアプリ42、ESE32、又はUICC34のいずれかを選択して、コマンドを送信する。
 このように、CLF31においては、ポーリングコマンドを受信した場合と、ポーリングコマンド以外のコマンドを受信した場合では、その処理プロセスが異なることになる。
[各ルーティング状態における受信パケットの処理プロセス]
 次に、上記の各ルーティング状態における受信パケットの処理プロセスについて説明する。
(ニュートラル状態における受信パケットの処理プロセス)
 図11は、ニュートラル状態における受信パケットの処理プロセスの概要を示す図である。
 ニュートラル状態における受信パケットの処理プロセスで行われるルーティングの方式には、コマンドコードルーティング、プロトコルルーティング、及びテクノロジールーティングの3種類がある。
 コマンドコードルーティング(command code routing)は、NFCリーダ12からのコマンドを常時監視して、特定のコマンドを受信した場合には、当該コマンドに対応付けられたターゲットに、受信パケットを送るルーティングの方式である。
 プロトコルルーティング(protocol routing)は、受信パケットがどのプロトコルになるかを、プロトコルベースで判別し、当該判別結果に応じたターゲットに、受信パケットを送るルーティングの方式である。プロトコルルーティングでは、例えば、受信パケットのプロトコルが、P2Pのプロトコルであるのか、又はT3Tのプロトコルであるかなどが判別される。以下、P2Pのプロトコルの判別結果に応じたルーティングを、P2Pプロトコルルーティングと称し、T3Tのプロトコルの判別結果に応じたルーティングをT3Tプロトコルルーティングと称する。
 テクノロジールーティング(technology routing)は、受信したパケットがどのプロトコルにも属さない場合に、あらかじめ特定されたターゲットに、受信パケットを送るルーティングの方式である。テクノロジールーティングでは、例えば、実装的にP2PやT3Tのプロトコルが無効になっていた場合に、NFC-Fのパケットは第1のターゲットに送り、NFC-Bのパケットは第2のターゲットに送るなどを、あらかじめ決めておくことで、受信パケットが、該当するターゲットに送られるようにすることができる。
 図11に示すように、NFCリーダ12からSENSF_REQコマンドを受信した場合には、SENSF_REQコマンドが、各ターゲットにブロードキャスト送信される。一方、NFCリーダ12からSENSF_REQ以外のコマンドを受信した場合には、まず、コマンドコードルーティングが行われ、確定ターゲットが選択された場合には、確定ターゲットに受信パケットが送られる。
 コマンドコードルーティングにて確定ターゲットが選択されなかった場合、P2Pプロトコルルーティング及びT3Tプロトコルルーティングが行われる。それらのプロトコルルーティングによって、確定ターゲットが選択された場合には、確定ターゲットに受信パケットが送られる。
 また、プロトコルルーティングにて確定ターゲットが選択されなかった場合、テクノロジールーティングが行われる。テクノロジールーティングにおいては、受信パケットの送信先が決まっているので、その送信先となるターゲットに受信パケットが送られる。
 なお、コマンドコードルーティングは、特定の運用における特定の機能を実現するために行われるものであるため、運用によっては実装されない場合もある。その場合には、CLF31は、SENSF_REQ以外のコマンドを受信したとき、コマンドコードルーティングを行わずに、プロトコルルーティングから開始する。そして、プロトコルルーティングにて確定ターゲットが選択されなかった場合、CLF31は、テクノロジールーティングを行うことになる。
 次に、図12を参照して、ニュートラル状態における受信パケットの処理プロセスの詳細について説明する。図12には、図11に示した各ルーティングの詳細な処理の内容が図示されている。
 コマンドコードルーティングでは、まず、受信パケットのコマンドコードのチェックが行われる(S11)。S11のチェック条件を満たしている場合には、受信パケットのNFCID2と、すべてのターゲットのNFCID2との比較が行われる(S12)。S12にてNFCID2が一致する場合には、所定のルーティングテーブルに、所定のターゲットが登録されているかのチェックが行われる(S13)。そして、S13のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。例えば、ルーティングテーブルにて、DH33がT3Tのプロトコルルーティングのターゲットとして登録されている場合には、DH33と通信可能となるので、T3Tアプリ42が確定ターゲットに選択される。
 上記のS11,S12,又はS13のチェック条件を満たさない場合、コマンドコードルーティングは終了し、次に、P2Pプロトコルルーティングが行われる。 
 P2Pプロトコルルーティングでは、受信したコマンドが、P2Pのコマンドであるかのチェックが行われる(S21)。S21のチェック条件を満たしている場合には、所定のルーティングテーブルのチェックが行われる(S22)。S22のチェック条件を満たしている場合、P2Pのプロトコルとして応答可能なコマンドであるかなどのチェックがさらに行われる(S23)。そして、S23のチェック条件を満たしている場合には、P2Pアプリ41が確定ターゲットに選択される。これにより、ルーティング状態は、ニュートラル状態からP2Pセレクト状態に遷移する。
 また、上記のS21のチェック条件を満たさない場合、P2Pプロトコルルーティングは終了し、次に、T3Tプロトコルルーティングが行われる。
 ここで、SENSF_REQコマンドに対する応答(SENSF_RESコマンド)の優先度であるが、初期状態では、P2Pアプリ41、ESE32、UICC34、T3Tアプリ42の順に優先度が高くなっている。そのため、SENSF_REQコマンドに対し、P2Pアプリ41を確定ターゲットの候補として選択してP2Pアプリ41のSENSF_RESコマンドを応答した後で、P2Pアプリ41に対する所定のコマンドが送られてこないと、トランザクションが不成立になってしまう。そこで、プロトコルルーティングにおいては、P2Pアプリ41に対する所定のコマンドを受信できなかった時点で(S21の「No」)、応答の優先度の変更を行い(S31)、P2Pアプリ41の優先度を下げる。
 例えば、CLF31は、ESE32、UICC34、T3Tアプリ42、P2Pアプリ41の順に優先度を変更する。これにより、CLF31は、次に、SENSF_REQコマンドを受信し、ターゲットにブロードキャスト送信した場合、変更された優先度に従って、優先度の最も高いESE32を確定ターゲットの候補として選択し、各ターゲットからのSENSF_RESコマンドのうち、ESE32の応答を、NFCリーダ12に返信することになる。
 なお、当該優先度の変更は、後述するS32のチェック条件を満たさない場合に、その後の処理として行ってもよい。
 図12の説明に戻り、T3Tプロトコルルーティングでは、受信パケットに格納されたNFCID2と、P2Pアプリ41以外のターゲット、すなわち、T3Tアプリ42、ESE32、UICC34のNFCID2との比較が行われる(S32)。S32にてNFCID2が一致する場合には、所定のルーティングテーブルに、所定のターゲットが登録されているかのチェックが行われる(S33)。そして、S33のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。これにより、ルーティング状態は、ニュートラル状態からT3Tセレクト状態に遷移する。
 上記のS22,S23,S32,S33のチェック条件を満たさない場合、プロトコルルーティングは終了し、次に、テクノロジールーティングが行われる。
 テクノロジールーティングでは、所定のルーティングテーブルのチェックが行われる(S41)。S41のチェック条件を満たしている場合には、当該ターゲットが、確定ターゲットとして選択される。これにより、ニュートラル状態からT3Tセレクト状態に遷移する。
 一方、S41のチェック条件を満たさない場合には、受信パケットは破棄され(S42)、受信パケットの処理は終了する。
 なお、SENSF_REQコマンドを受信した場合には、SENSF_REQプロセス処理によって、受信パケットに格納されたパラメータや所定のルーティングテーブルのチェックが行われる(S51)。S51のチェック条件を満たしている場合には、SENSF_REQコマンドは、各ターゲットにブロードキャスト送信される。一方、S51のチェック条件を満たさない場合には、受信パケットは破棄される(S52)。
 このように、ニュートラル状態における受信パケットの処理プロセスでは、受信パケットの評価を行い、評価結果に応じて、確定ターゲットが選択される。また、確定ターゲットが選択されると、ルーティング状態は、ニュートラル状態からP2Pセレクト状態又はT3Tセレクト状態に遷移する。さらに、確定ターゲットの候補として選択したP2Pアプリ41からの応答をNFCリーダ12に返信したにもかかわらず、P2PプロトコルルーティングにてP2Pアプリ41が確定ターゲットに選択されなかった場合には、応答の優先度の変更が行われ、P2Pアプリ41の優先度が下げられる。
(T3Tセレクト状態における受信パケットの処理プロセス)
 図13は、T3Tセレクト状態における受信パケットの処理プロセスの概要を示す図である。
 T3Tセレクト状態における受信パケットの処理プロセスで行われるルーティングの方式は、コマンドコードルーティング及びP2Pプロトコルルーティングとなる。
 図13に示すように、NFCリーダ12からSENSF_REQコマンドを受信した場合には、SENSF_REQコマンドが、各ターゲットにブロードキャスト送信される。一方、NFCリーダ12からSENSF_REQ以外のコマンドを受信した場合には、まず、コマンドコードルーティングが行われる。
 また、コマンドコードルーティングにて確定ターゲットが選択されなかった場合、P2Pプロトコルルーティングが行われる。すなわち、前述した状態遷移図(図6)に示したように、ルーティング状態が、T3Tセレクト状態からP2Pセレクト状態に遷移する場合があるため、T3Tセレクト状態においても、P2Pプロトコルルーティングが行われる。P2Pプロトコルルーティングにおいて、P2Pアプリ41が確定ターゲットに選択された場合、ルーティング状態は、T3Tセレクト状態からP2Pセレクト状態に遷移する。一方、P2Pアプリ41が確定ターゲットに選択されなかった場合、確定ターゲットは、現在のターゲットのまま変動せず、さらに、ルーティング状態もT3Tセレクト状態から変動しないことになる。
 なお、前述したように、コマンドコードルーティングが実装されない場合には、P2Pプロトコルルーティングのみが行われることになる。
 次に、図14を参照して、T3Tセレクト状態における受信パケットの処理プロセスの詳細について説明する。図14には、図13に示した各ルーティングの詳細な処理の内容が図示されている。
 図14において、コマンドコードルーティング及びP2Pプロトコルルーティングは、図12と同様に行われるため、その説明は省略する。ただし、図14のS21,S22,S23のチェック条件を満たさない場合には、プロトコルルーティングは終了し、確定ターゲット及びルーティング状態は変動しないため、受信パケットは、現在のターゲットに送られることになる。なお、図14の処理プロセスでは、前述した応答の優先度の変更は行われない。
 また、SENSF_REQコマンドを受信した場合には、SENSF_REQプロセス処理が、図12と同様に行われる。
 このように、T3Tセレクト状態における受信パケットの処理プロセスでは、コマンドコードルーティング及びP2Pプロトコルルーティングのみが行われ、それらのルーティングの評価結果に応じて、確定ターゲットが選択される。
(P2Pセレクト状態における受信パケットの処理プロセス)
 図15は、P2Pセレクト状態における受信パケットの処理プロセスを示す図である。
 図15に示すように、P2Pセレクト状態における受信パケットの処理プロセスにおいては、CLF31は、NFCリーダ12からの受信パケットを、すべて、P2Pアプリ41に送信する。
 このように、P2Pセレクト状態における受信パケットの処理プロセスでは、受信パケットの評価は行われず、受信パケットは、常に確定ターゲットであるP2Pアプリ41に送信される。
 以上、受信パケットの処理プロセスについて説明した。
[具体的な運用例]
 次に、図16及び図17のシーケンス図を参照して、本技術を利用した具体的な運用例について説明する。
 図16及び図17においては、NFCリーダ12からのコマンドに対する、CLF31、ESE32、UICC34の動作が示されている。また、論理ターゲットであるP2Pアプリ41L及びT3Tアプリ42Lについては、CLF31内で処理される。ここで、NFCリーダ12の所望とするアプリケーションプログラムは、ESE32に存在するものとする。
 また、図中の右側に示される、「SENSF_RES Priority order」は、応答の優先度におけるターゲットの並び順の状態を示している。「Normal order」は、P2Pアプリ41の優先度が最も高い状態の並び順を意味する。また、「P2P deprioritised」は、P2Pアプリ41の優先度が下げられた状態の並び順を意味する。
 「P2P_RSP_FLG」は、P2Pアプリ41のSENSF_RESコマンドの応答時にセットされるフラグである。「P2P_RSP_FLG」は、P2Pアプリ41以外のSENSF_RESコマンドの応答時、又はルーティング状態がニュートラル状態に戻ったとき、クリアされる。また、「Routing State」は、前述したルーティング状態を示すもので、ニュートラル状態、P2Pセレクト状態、又はT3Tセレクト状態のいずれかの状態となる。
 図16に示すように、NFCリーダ12からSENSF_REQコマンドが送信されると、CLF31は、SENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信する。ブロードキャスト送信されたSENSF_REQコマンドは、ESE32及びUICC34にそれぞれ受信され、その応答がCLF31に返信される。また、CLF31は、SENSF_REQコマンドに対する、P2Pアプリ41L及びT3Tアプリ42Lに関する処理を行う。
 CLF31は、初期状態ではP2Pアプリ41の優先度が最も高いので、P2Pアプリ41を確定ターゲットの候補として選択し、P2Pアプリ41のNFCID2を含むSENSF_RESコマンドを、NFCリーダ12に返信する。すると、NFCリーダ12は、CLF31からのSENSF_RESコマンドに応じて、P2Pアプリ41のNFCID2を含むRequest System codeコマンドを送信する。CLF31は、NFCリーダ12からのRequest System codeコマンドを、ESE32に送信するが、当該コマンドを誤ったターゲットに送信してしまったため、応答を得ることはできない。結果としてNFCリーダ12も応答を得ることができず、この場合、トランザクションに失敗したことになる(図中の「FAIL」)。
 すなわち、CLF31において、ポーリングパラメータのSC(System Code)が“FFFF”となるSENSF_REQコマンドに対して、P2Pアプリ41のSENSF_RESコマンドを応答した後で、ATR_REQ,Ad-hoc通信用コマンドセット,Get Container Issue Information以外のコマンドを受信すると、当該トランザクションは不成立となる。ここで、ATR_REQコマンドは、NFC規格により規定されているP2P通信で用いられるコマンドである。また、Ad-hoc通信用コマンドセットは、所定の規格に準拠したアドホック通信用のコマンドである。Get Container Issue Informationは、所定の規格に準拠したICチップに関連する情報を取得するためのコマンドである。
 この場合、CLF31は、ターゲットからの応答の優先度を、ESE32、UICC34、T3Tアプリ42、P2Pアプリ41の順に変更して、P2Pアプリ41の優先度を下げる。これにより、P2Pアプリ41以外の次のトランザクションが成立されるようにする。なお、CLF31は、例えば5~10秒間など、所定の期間のみ優先度の変更を行い、当該期間経過後に優先度を元に戻して、P2Pアプリ41の優先度が最も高くなるようにする。具体的には、図16の「Timer start」から、図17の「Timer expire」までの期間が、優先度を変更する期間となる。
 一方、NFCリーダ12は、トランザクションが失敗した場合、RF信号を一度オフしてから、再度オンする。そして、NFCリーダ12は、再度、SENSF_REQコマンドを送信する。CLF31は、NFCリーダ12からのSENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信する。ESE32及びUICC34は、SENSF_RESコマンドをそれぞれ返信する。
 CLF31は、応答の優先度が変更されESE32の優先度が最も高いので、ESE32を確定ターゲットの候補として選択し、ESE32のNFCID2を含むSENSF_RESコマンドを、NFCリーダ12に返信する。すると、NFCリーダ12から、ESE32のNFCID2を含むRequest System codeコマンドが送信されるので、CLF31は、当該コマンドをESE32に送信する。このとき、CLF31は、確定ターゲットの候補として選択されていたESE32を、確定ターゲットとして選択する。また、「Routing State」は、ニュートラル状態からT3Tセレクト状態に遷移する。
 Request System codeコマンドには、ESE32のNFCID2が含まれているので、ESE32は、当該コマンドに応じて、Request System code responseコマンドを返信する。Request System code responseコマンドは、CLF31を経由して、NFCリーダ12に送信される。このRequest System code responseコマンドには、ESE32のSCとして“FE00”が含まれている。
 NFCリーダ12は、Request System code responseコマンドに応じて、当該コマンドにて取得したSCを用いて、SENSF_REQコマンドを送信する。CLF31は、NFCリーダ12からのSENSF_REQコマンドを受信し、各ターゲットにブロードキャスト送信するが、SCが“FE00”となるサービスにUICC34が対応していないため、ESE32からのみSENSF_RESコマンドが返信されることになる。CLF31は、ESE32からのSENSF_RESコマンドを、NFCリーダ12に返信する。
 NFCリーダ12は、ESE32のNFCID2を含むSENSF_RESコマンドに応じて、ESE32に対するESE32のNFCID2を含むRequest Serviceコマンドを送信する。CLF31は、NFCリーダ12からのRequest Serviceコマンドを、ESE32に送信する。ESE32は、CLF31からのRequest Serviceコマンドに応じて、Request Service responseコマンドを返信する。CLF31は、ESE32からのRequest Service responseコマンドを、NFCリーダ12に返信する。
 このように、P2Pアプリ41に対するトランザクションが不成立となった場合、ターゲットからの応答の優先度を変更することで、その時点で最も優先度が高くなったESE32に対するトランザクションを成立させることができる。また、仮に、ESE32に対するトランザクションが不成立となった場合には、その次に優先度の高いUICC34、T3Tアプリ42の順にトランザクションの成立を試みることになる。
 以降、所定の期間の終了時刻(図17の「Timer expire」)まで、同様の処理が繰り返され、NFCリーダ12とESE32の間で処理が行われる。なお、図17に示すように、所定の期間中に、NFCリーダ12によりRF信号がオフされたとしても、CLF31では、優先度の変更に関する情報を保持しているため、RF信号がオンされた後は、ESE32が最も高い優先度であるとして、処理を継続することができる。
 そして、所定の期間の終了時刻が経過すると、CLF31は、応答の優先度を初期状態に戻して、P2Pアプリ41の優先度が最も高くなるようにする。これにより、例えば、その後、他のNFCリーダと近接通信を行う場合には、優先度が最も高いP2Pアプリ41に対するトランザクションの成立から試みることになる。
 以上のように、ある運用では、P2Pアプリ41以外のターゲットを通信対象とする場合にもかかわらず、最初にNFCリーダ12から送られるSENSF_REQコマンドに含まれるポーリングパラメータのSCが“FFFF”で、RC(Request Code)が"1"以外となる場合、すなわち、トランザクションの最初のコマンドにて、P2P通信とまったく同じポーリングパラメータにて通信を開始する場合がある。この場合、CLF31は、P2Pアプリ41の応答を返信するのか、又はP2Pアプリ41以外のターゲットの応答を返信するのかを、コマンドからは判別することができない。そのため、当該SENSF_REQコマンドに対し、P2Pアプリ41のSENSF_RESコマンドを応答した後で、ATR_REQ等の所定のコマンド以外のコマンドを受信すると、当該トランザクションは不成立となってしまう。
 そこで、本技術を利用した運用では、このような条件が満たされた段階で、所定の期間だけ、SENSF_REQコマンドに対する応答の優先度を変更して、次のトランザクションが成立されるようにしている。これにより、CLF31は、どのターゲットの応答を返信するかを判別することができない場合でも、P2Pアプリ41以外のターゲットを順次、確定ターゲットの候補とすることができるので、NFCリーダ12が所望とするターゲットを確実に選択することが可能となる。その結果、NFCリーダ12とターゲットとの間で行われる通信を、迅速に確立することができる。
[NFCID2の抽出及び一時的保持]
 次に、図18及び図19を参照して、NFCID2の抽出及び一時的保持に関する処理について説明する。
 CLF31は、SENSF_RESコマンドの応答時に、ESE32及びUICC34からのSENSF_RESコマンドのパケットに格納されたNFCID2を抽出する。図18は、SENSF_RESコマンドのパケットにおけるNFCID2の格納位置を示している。
 CLF31は、ESE32及びUICC34のNFCID2をそれぞれ1つずつ、ターゲットと対応付けてメモリ31Aに保持する。CLF31は、SENSF_REQコマンドに対する応答がある度にNFCID2を抽出して、メモリ31Aに保持された対応情報を更新する。なお、P2Pアプリ41及びT3Tアプリ42のNFCID2については、例えば、所定の規格に準拠した識別情報が、あらかじめメモリ31Aに保持される。
 具体的には、図19に示すように、CLF31は、NFCリーダ12からのSENSF_REQコマンド(SC=“FFFF”)をブロードキャスト送信し、その応答を、ESE32及びUICC34から受信する。CLF31は、ESE32及びUICC34からのSENSF_RESコマンドに含まれるNFCID2を抽出し、メモリ31Aに保持する。この例では、ESE32のNFCID2として“NFCID2_ese_0”、UICC34のNFCID2として“NFCID2_uicc_0”がそれぞれ抽出され、メモリ31Aに保持される。
 また、再度、NFCリーダ12からSENSF_REQコマンド(SC=“FF00”)が送信されると、CLF31は、当該SENSF_REQコマンドをブロードキャスト送信し、その応答を、ESE32からのみ受信する。CLF31は、ESE32からのSENSF_RESコマンドに含まれるNFCID2として“NFCID2_ese_1”を抽出し、メモリ31Aに保持する。
 このように、各ターゲットのNFCID2の値は、常に同じとは限らないので、CLF31は、SENSF_RESコマンドを受信する度に、メモリ31Aに保持されたNFCID2の値を更新する。
[NFCID2のリプレイス処理]
 次に、図20及び図21を参照して、NFCID2のリプレイス処理について説明する。
 図20に示すように、CLF31は、特定のコマンドコードを受信して、ターゲットを強制的に変更した場合、NFCリーダ12との通信用のNFCID2と、ターゲットとの通信用のNFCID2を置換して通信する必要がある。
 例えば、CLF31は、Get Container Issue Informationコマンドを受信した場合に、強制的にターゲットをESE32に変更するとき、ESE32のNFCID2を使用する必要があるため、ESE32のNFCID2に置換してから、ESE32との通信を行う。また、CLF31は、NFCリーダ12に応答をする場合には、NFCリーダ12から受信したコマンドに含まれるNFCID2に再度置換してから応答する。
 また、例えば、CLF31は、Propose Ad-hoc Modeコマンドを受信した場合に、強制的にターゲットをDH33に変更するとき、DH33のT3Tアプリ42のNFCID2に置換してから、T3Tアプリ42と通信を行う。また、NFCリーダ12との通信を行う場合には、当該置換前のNFCID2を用いて通信が行われる。
 具体的には、図21に示すように、CLF31は、NFCリーダ12からのSENSF_REQコマンド(SC=“FFFF”)をブロードキャスト送信し、その応答を、ESE32及びUICC34から受信する。CLF31は、SENSF_RESコマンドに含まれるNFCID2を抽出し、メモリ31Aに保持する。そして、CLF31は、優先度に従って、P2Pアプリ41のNFCID2を含むSENSF_RESコマンドを返信する。
 また、NFCリーダ12からGet Container Issue Informationコマンドが送信されると、CLF31は、当該コマンドに含まれるNFCID2を、P2Pアプリ41からESE32のものに置換してから、ESE32に送信する。すると、当該コマンドに対する応答がESE32から送信されるので、CLF31は、応答コマンドに含まれるNFCID2を、ESE32からP2Pアプリ41のものに置換してから、NFCリーダ12に送信する。
 このように、コマンドに含まれるNFCID2を置換することで、NFCリーダ12により指定されたコマンドの送り先を、強制的に変更することができる。このようなリプレイス処理は、例えば、上記のコマンドコードルーティングを行う場合には、必要な処理となる。
[ターゲット解除処理]
 次に、ターゲットの解除処理について説明する。CLF31は、所定のターゲット解除条件に基づいて、確定ターゲットを解除する。この解除条件は、ユーザによる実行中のアプリケーションプログラムの終了操作をトリガとするものと、RF信号の消失などの外部要因によるものとがある。
(RF_DEACTIVATE_CMD受信による解除)
 CLF31は、DH33から、RF_DEACTIVATE_CMDコマンド(Idle Mode,DH_Request)などの特定のコマンドを受信した場合、NFCリーダ12との通信そのものが終了するので、確定ターゲットを解除する。なお、当該コマンドが受信された場合には、いかなるルーティング状態にあっても、確定ターゲットが解除される。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(SENSF_REQ受信時におけるSENSF_RES応答による解除)
 CLF31は、ルーティング状態がT3Tセレクト状態にある場合に、NFCリーダ12からのSENSF_REQコマンドをブロードキャスト送信して、SENSF_RESコマンドの応答があったときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(RLS_REQ受信による解除)
 CLF31は、P2Pアプリ41が確定ターゲットに選択されている場合に、RLS_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(DSL_REQ受信による解除)
 CLF31は、P2Pアプリ41が確定ターゲットに選択されている場合に、DSL_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(RF信号の消失による解除)
 CLF31は、P2Pアプリ41が確定ターゲットに選択されている場合に、RF信号のオフが検出された場合には、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(NFC-Aへのtechnology changeを伴うPSL_REQによる解除)
 CLF31は、P2Pアプリ41が確定ターゲットに選択されている場合に、NFC-Aへのtechnology changeを伴うPSL_REQコマンドを受信したときには、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。
(その他の解除条件)
 CLF31は、デバイスリセットが発生した場合やCORE_RESET_CMDコマンドを受信した場合など、RF_DEACTIVATE_CMDコマンド以外のRFST_IDLE状態への遷移を引き起こす事象が発生した場合には、確定ターゲットを解除する。この場合、ルーティング状態は、ニュートラル状態に遷移する。なお、CORE_RESET_CMDコマンドは、所定の規格に準拠したリセットを指示するためのコマンドである。
 以上、ターゲット解除処理について説明した。
[コマンド対応処理]
 次に、図22のフローチャートを参照して、NFCリーダ12からのコマンドを受信した際に、CLF31にて実行されるコマンド対応処理について説明する。
 ステップS101において、パケット受信処理部101は、NFCリーダ12からコマンドを受信したか否かを判定する。ステップS101において、コマンドを受信したと判定された場合、処理は、ステップS102に進められる。
 ステップS102において、パケット受信処理部101は、受信したコマンドがSENSF_REQコマンドであるか否かを判定する。ステップS102において、SENSF_REQコマンドであると判定された場合、処理は、ステップS103に進められる。
 ステップS103において、パケット受信処理部101は、SENSF_REQコマンドを、各ターゲットにブロードキャスト送信する。
 ステップS104において、パケット受信処理部101は、SENSF_REQコマンドを受信したターゲットから返信されるSENSF_RESコマンドを受信する。
 ステップS105において、パケット受信処理部101は、応答のあったターゲットの中から、応答の優先度に従って、応答を返信する確定ターゲットの候補を選択する。なお、前述の通り、応答の優先度は、初期状態では、P2Pアプリ41が最も高い優先度となる。
 ステップS106において、パケット受信処理部101は、ステップS105にて選択した確定ターゲットの候補からのSENSF_RESコマンドを、NFCリーダ12に送信する。これにより、NFCリーダ12は、NFCデバイス11からのSENSF_RESコマンドを受信し、当該コマンドに応じた処理を行う。
 一方、ステップS102において、受信したコマンドがSENSF_REQコマンド以外のコマンドであると判定された場合、処理は、ステップS107に進められる。
 ステップS107において、パケット受信処理部101は、現在のルーティング状態がニュートラル状態であるか否かを判定する。ステップS107において、現在のルーティング状態がニュートラル状態であると判定された場合、処理は、ステップS108に進められる。
 ステップS108において、パケット受信処理部101は、ニュートラル状態における受信パケットの処理を行う。
 ここで、図23のフローチャートを参照して、図22のステップS108に対応するニュートラル状態における受信パケットの処理について説明する。
 ステップS131において、パケット受信処理部101は、ニュートラル状態における受信パケットの処理を行う。当該受信パケット処理では、前述した図11及び図12で説明したように、コマンドコードルーティング、プロトコルルーティング、及びテクノロジールーティングによって、受信パケットの評価が行われ、その評価結果に応じて、確定ターゲットが選択される。
 また、ルーティング状態管理部102は、確定ターゲットが選択された場合、ルーティング状態を、現在のニュートラル状態から、P2Pセレクト状態又はT3Tセレクト状態に遷移させる。
 ステップS132において、パケット受信処理部101は、NFCリーダ12に対する直前の応答として、P2Pアプリ41のSENSF_RESコマンドの応答をしたか否かを判定する。ステップS132において、直前にP2Pアプリ41のSENSF_RESコマンドの応答をしたと判定された場合、処理は、ステップS133に進められる。
 ステップS133において、パケット受信処理部101は、ステップS131の処理によって、P2Pアプリ41が確定ターゲットに選択されたか否かを判定する。ステップS133において、P2Pアプリ41が確定ターゲットに選択されなかったと判定された場合、処理は、ステップS134に進められる。
 ステップS134において、優先度管理部103は、優先度の変更を行う。すなわち、この場合、確定ターゲットの候補として選択されたP2Pアプリ41のSENSF_RESコマンドの応答をしたのにもかかわらず、NFCリーダ12からP2Pアプリ41に対するコマンド以外のコマンドを受信したことになるので、優先度の変更が行われる。例えば、優先度管理部103は、初期状態では最も高い優先度となるP2Pアプリ41の優先度を下げて、ESE32、UICC34、T3Tアプリ42、P2Pアプリ41の順に優先度を変更する。この場合、P2Pアプリ41の優先度は、ターゲットの中で最も低い優先度となる。
 なお、変更後の優先度の順序であるが、上記の順序に限らず、他の順序に並び替えることも可能である。例えば、ターゲットが、ESE32、UICC34、及びP2Pアプリ41からなる場合に、P2Pアプリ41が確定ターゲットに選択されなかったとき、優先度管理部103は、ESE32、UICC34、P2Pアプリ41の順となるように優先度を変更することができる。この場合に、優先度管理部103は、ESE32、P2Pアプリ41、UICC34の順となるように優先度を変更してもよい。
 また、例えば、ターゲットが、ESE32及びUICC34のうちいずれか一方しか存在しなかった場合、優先度管理部103は、P2Pアプリ41の優先度を、ESE32及びUICC34のいずれか一方の次の優先度に変更する。すなわち、ターゲットには、ESE32及びUICC34のいずれか一方又は双方が少なくとも含まれており、優先度管理部103は、P2Pアプリ41が確定ターゲットに選択されなかった場合、P2Pアプリ41の優先度を、ESE32及びUICC34のいずれか一方又は双方の次の優先度に変更する。
 さらに、優先度管理部103は、NFCリーダ12の動作シーケンスに応じて、応答の優先度を変更するようにしてもよい。
 このように、変更後の優先度の順序は、例えばターゲットの種類や運用の形態などに応じて、任意に設定されるものであり、原則として、最も高い優先度であったP2Pアプリ41の優先度が低くなるように並び替えられることになる。
 ステップS132において、直前にP2Pアプリ41のSENSF_RESコマンドの応答をしていないと判定された場合には、ステップS133及びS134はスキップされる。また、ステップS133において、P2Pアプリ41が確定ターゲットに選択されたと判定された場合には、ステップS134はスキップされる。
 ステップS134の処理が終了又はスキップされると、処理は、図22のステップS108に戻り、それ以降の処理が行われる。
 また、ステップS107において、現在のルーティング状態がニュートラル状態ではないと判定された場合、処理は、ステップS109に進められる。
 ステップS109において、パケット受信処理部101は、現在のルーティング状態がT3Tセレクト状態であるか否かを判定する。ステップS109において、現在のルーティング状態がT3Tセレクト状態であると判定された場合、処理は、ステップS110に進められる。
 ステップS110において、パケット受信処理部101は、T3Tセレクト状態における受信パケット処理を行う。当該受信パケット処理では、前述した図13及び図14で説明したように、コマンドコードルーティング及びP2Pプロトコルルーティングによって、受信パケットの評価が行われ、その評価結果に応じて、確定ターゲットが選択される。
 一方、ステップS109において、現在のルーティング状態がT3Tセレクト状態でない、つまり、P2Pセレクト状態であると判定された場合、処理は、ステップS111に進められる。
 ステップS111において、パケット受信処理部101は、P2Pセレクト状態における受信パケット処理を行う。当該受信パケット処理では、前述した図15で説明したように、受信パケットの評価は行われず、受信パケットは、常にP2Pアプリ41に送信される。
 ステップS101においてコマンドを受信していないと判定された場合、又はステップS108,S110,S111の処理が終了した場合、処理は、ステップS112に進められる。
 ステップS112において、優先度管理部103は、図23のステップS134にて応答の優先度の変更を行ったか否かを判定する。ステップS112において、優先度の変更を行ったと判定された場合、処理は、ステップS113に進められる。
 ステップS113において、優先度管理部103は、所定の期間を経過したか否かを判定する。ステップS113において、所定の期間を経過したと判定された場合、処理は、ステップS114に進められる。
 ステップS114において、優先度管理部103は、応答の優先度を初期状態に戻して、P2Pアプリ41の優先度が最も高くなるように変更する。
 なお、ステップS112において優先度を変更していないと判定された場合、ステップS113において所定の期間を経過していないと判定された場合、又はステップS114の処理が終了した場合、処理は、ステップS101に戻り、それ以降の処理が繰り返される。
 以上、コマンド対応処理について説明した。コマンド対応処理によれば、ルーティング状態に応じた受信パケットの処理プロセスが行われる。また、ニュートラル状態における受信パケットの処理プロセスでは、受信パケットの評価が行われ、P2Pアプリ41のSENSF_RESコマンドの応答をしたのにもかかわらず、P2Pアプリ41が確定ターゲットに選択されなかった場合には、応答の優先度の変更が行われ、P2Pアプリ41の優先度が下げられる。
[本技術を適用したコンピュータの説明]
 前述した一連の処理は、ハードウェアにより実行することもできるし、ソフトウェアにより実行することもできる。一連の処理をソフトウェアにより実行する場合には、そのソフトウェアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウェアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
 図24は、前述した一連の処理をプログラムにより実行するコンピュータのハードウェアの構成例を示すブロック図である。
 コンピュータ200において、CPU(Central Processing Unit)201,ROM(Read Only Memory)202,RAM(Random Access Memory)203は、バス204により相互に接続されている。
 バス204には、さらに、入出力インタフェース205が接続されている。入出力インタフェース205には、入力部206、出力部207、記憶部208、通信部209、及びドライブ210が接続されている。
 入力部206は、キーボード、マウス、マイクロフォンなどよりなる。出力部207は、ディスプレイ、スピーカなどよりなる。記憶部208は、ハードディスクや不揮発性のメモリなどよりなる。通信部209は、ネットワークインタフェースなどよりなる。ドライブ210は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア211を駆動する。
 以上のように構成されるコンピュータ200では、CPU201が、例えば、記憶部208に記憶されているプログラムを、入出力インタフェース205及びバス204を介して、RAM203にロードして実行することにより、前述した一連の処理が行われる。
 コンピュータ200(CPU201)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア211に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線又は無線の伝送媒体を介して提供することができる。
 コンピュータ200では、プログラムは、リムーバブルメディア211をドライブ210に装着することにより、入出力インタフェース205を介して、記憶部208にインストールすることができる。また、プログラムは、有線又は無線の伝送媒体を介して、通信部209で受信し、記憶部208にインストールすることができる。その他、プログラムは、ROM202や記憶部208に、あらかじめインストールしておくことができる。
 なお、コンピュータ200が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
 ここで、本明細書において、コンピュータ200に各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理(例えば、並列処理あるいはオブジェクトによる処理)も含むものである。
 また、プログラムは、1のコンピュータにより処理されるものであってもよいし、複数のコンピュータによって分散処理されるものであってもよい。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであってもよい。
 さらに、本明細書において、システムとは、複数の構成要素(装置、モジュール(部品)等)の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、1つの筐体の中に複数のモジュールが収納されている1つの装置は、いずれも、システムである。
 なお、本技術の実施の形態は、前述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
 例えば、本技術は、1つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
 また、前述のフローチャートで説明した各ステップは、1つの装置で実行する他、複数の装置で分担して実行することができる。
 さらに、1つのステップに複数の処理が含まれる場合には、その1つのステップに含まれる複数の処理は、1つの装置で実行する他、複数の装置で分担して実行することができる。
 なお、本技術は、以下のような構成をとることができる。
(1)
 それぞれが所定の処理を実行する複数のターゲットと、
 前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
 を備え、
 前記複数のターゲットは、P2P(Peer to Peer)のアプリケーションを含み、
 前記フロントエンドは、
  前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
  前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
  前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
  前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
 通信装置。
(2)
 前記フロントエンドは、前記外部装置から前記第1のコマンドを受信した場合、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信する
 (1)に記載の通信装置。
(3)
 前記複数のターゲットのうち、前記P2Pのアプリケーションを除く他のターゲットは、セキュアエレメント及びUICC(Universal Integrated Circuit Card)のいずれか一方又は双方を少なくとも含んでおり、
 前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を、前記セキュアエレメント及び前記UICCのいずれか一方又は双方の次の優先度に変更する
 (1)又は(2)に記載の通信装置。
(4)
 前記フロントエンドは、前記セキュアエレメント、前記UICC、前記P2Pのアプリケーションの順となるように前記優先度を変更する
 (3)に記載の通信装置。
(5)
 前記フロントエンドは、前記セキュアエレメント、前記P2Pのアプリケーション、前記UICCの順となるように前記優先度を変更する
 (3)に記載の通信装置。
(6)
 前記他のターゲットは、さらに、所定の規格に準拠した所定のアプリケーションを含んでおり、
 前記フロントエンドは、前記セキュアエレメント、前記UICC、前記所定のアプリケーション、前記P2Pのアプリケーションの順となるように前記優先度を変更する
 (3)に記載の通信装置。
(7)
 前記フロントエンドは、前記P2Pのアプリケーションの優先度を、最も低い優先度に変更する
 (1)乃至(3)のいずれかに記載の通信装置。
(8)
 前記フロントエンドは、前記外部装置の動作シーケンスに応じて、前記優先度を変更する
 (1)乃至(3)のいずれかに記載の通信装置。
(9)
 前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を変更した場合に、あらかじめ設定された所定の期間を経過したとき、前記P2Pのアプリケーションの前記優先度を、最も高い優先度に戻す
 (1)乃至(3)のいずれかに記載の通信装置。
(10)
 前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
 (1)乃至(3)のいずれかに記載の通信装置。
(11)
 前記フロントエンドは、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信した場合に、いずれかのターゲットからの応答があったとき、前記確定ターゲットを、前記外部装置の通信対象から解除する
 (10)に記載の通信装置。
(12)
 前記フロントエンドは、前記第2のコマンドに含まれる識別情報と、前記確定ターゲットの候補の識別情報が一致する場合、前記確定ターゲットの候補を、前記確定ターゲットとして選択する
 (1)乃至(11)のいずれかに記載の通信装置。
(13)
 それぞれが所定の処理を実行する複数のターゲットと、
 前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
 を備える通信装置の制御方法であって、
 前記複数のターゲットは、
  前記外部装置から受信した、P2P(Peer to Peer)のアプリケーションを含み、
 前記フロントエンドが、
  前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
  前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
  前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
  前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
 ステップを含む制御方法。
(14)
 それぞれが所定の処理を実行する複数のターゲットと、
 P2P(Peer to Peer)のアプリケーションを含む前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
 を備える通信装置の制御用のプログラムであって、
 前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
 前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
 前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
 前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
 ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
 11 NFCデバイス, 12 NFCリーダ, 31 CLF, 31A メモリ, 32 ESE, 33 DH, 34 UICC, 41,41L P2Pアプリ, 42,42L T3Tアプリ, 101 パケット受信処理部, 102 ルーティング状態管理部, 103 優先度管理部, 104 無線通信制御部, 200 コンピュータ, 201 CPU

Claims (14)

  1.  それぞれが所定の処理を実行する複数のターゲットと、
     前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
     を備え、
     前記複数のターゲットは、P2P(Peer to Peer)のアプリケーションを含み、
     前記フロントエンドは、
      前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
      前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
      前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
      前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
     通信装置。
  2.  前記フロントエンドは、前記外部装置から前記第1のコマンドを受信した場合、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信する
     請求項1に記載の通信装置。
  3.  前記複数のターゲットのうち、前記P2Pのアプリケーションを除く他のターゲットは、セキュアエレメント及びUICC(Universal Integrated Circuit Card)のいずれか一方又は双方を少なくとも含んでおり、
     前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を、前記セキュアエレメント及び前記UICCのいずれか一方又は双方の次の優先度に変更する
     請求項2に記載の通信装置。
  4.  前記フロントエンドは、前記セキュアエレメント、前記UICC、前記P2Pのアプリケーションの順となるように前記優先度を変更する
     請求項3に記載の通信装置。
  5.  前記フロントエンドは、前記セキュアエレメント、前記P2Pのアプリケーション、前記UICCの順となるように前記優先度を変更する
     請求項3に記載の通信装置。
  6.  前記他のターゲットは、さらに、所定の規格に準拠した所定のアプリケーションを含んでおり、
     前記フロントエンドは、前記セキュアエレメント、前記UICC、前記所定のアプリケーション、前記P2Pのアプリケーションの順となるように前記優先度を変更する
     請求項3に記載の通信装置。
  7.  前記フロントエンドは、前記P2Pのアプリケーションの優先度を、最も低い優先度に変更する
     請求項3に記載の通信装置。
  8.  前記フロントエンドは、前記外部装置の動作シーケンスに応じて、前記優先度を変更する
     請求項3に記載の通信装置。
  9.  前記フロントエンドは、前記P2Pのアプリケーションの前記優先度を変更した場合に、あらかじめ設定された所定の期間を経過したとき、前記P2Pのアプリケーションの前記優先度を、最も高い優先度に戻す
     請求項3に記載の通信装置。
  10.  前記フロントエンドは、所定のターゲット解除条件に基づいて、前記確定ターゲットを、前記外部装置の通信対象から解除する
     請求項3に記載の通信装置。
  11.  前記フロントエンドは、前記第1のコマンドを、前記複数のターゲットにブロードキャスト送信した場合に、いずれかのターゲットからの応答があったとき、前記確定ターゲットを、前記外部装置の通信対象から解除する
     請求項10に記載の通信装置。
  12.  前記フロントエンドは、前記第2のコマンドに含まれる識別情報と、前記確定ターゲットの候補の識別情報が一致する場合、前記確定ターゲットの候補を、前記確定ターゲットとして選択する
     請求項1に記載の通信装置。
  13.  それぞれが所定の処理を実行する複数のターゲットと、
     前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
     を備える通信装置の制御方法であって、
     前記複数のターゲットは、P2P(Peer to Peer)のアプリケーションを含み、
     前記フロントエンドが、
      前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
      前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
      前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
      前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
     ステップを含む制御方法。
  14.  それぞれが所定の処理を実行する複数のターゲットと、
     P2P(Peer to Peer)のアプリケーションを含む前記複数のターゲットの中から、外部装置の通信対象となる確定ターゲットを選択して、前記外部装置との近接通信を行うフロントエンドと
     を備える通信装置の制御用のプログラムであって、
     前記外部装置から受信した、前記確定ターゲットの候補を選択するための第1のコマンドを、前記複数のターゲットに送信し、
     前記確定ターゲットの候補を選択するにあたり前記P2Pのアプリケーションを最も高い優先度のターゲットとし、前記確定ターゲットの候補を選択し、
     前記外部装置から受信した、所定のターゲットの識別情報を含む第2のコマンドに基づいて、前記確定ターゲットの候補を、前記確定ターゲットとして選択し、
     前記P2Pのアプリケーションが前記確定ターゲットの候補として選択された場合に、前記P2Pのアプリケーションが前記確定ターゲットに選択されなかったとき、前記確定ターゲットの候補の選択における前記P2Pのアプリケーションの優先度を下げる
     ステップを含む処理を、通信装置のコンピュータに実行させるプログラム。
PCT/JP2013/054671 2012-03-07 2013-02-25 通信装置、制御方法、及びプログラム WO2013133058A1 (ja)

Priority Applications (10)

Application Number Priority Date Filing Date Title
CN201380011796.4A CN104428796B (zh) 2012-03-07 2013-02-25 通信设备、控制方法、程序和前端
JP2014503767A JP6162683B2 (ja) 2012-03-07 2013-02-25 通信装置、制御方法、プログラム、及びフロントエンド
IN7294DEN2014 IN2014DN07294A (ja) 2012-03-07 2013-02-25
EP17187515.6A EP3276537B1 (en) 2012-03-07 2013-02-25 Communication device, control method, program, and front end
KR1020147024308A KR102040348B1 (ko) 2012-03-07 2013-02-25 통신 장치, 제어 방법, 비일시적 컴퓨터 판독가능 기록 매체 및 프론트 엔드
US14/382,070 US9237409B2 (en) 2012-03-07 2013-02-25 Communication device, control method, program, and front end
EP13758604.6A EP2824611B1 (en) 2012-03-07 2013-02-25 Communication device, control method, and program
US14/955,582 US9444519B2 (en) 2012-03-07 2015-12-01 Communication device, control method, program, and front end
US15/220,020 US10305547B2 (en) 2012-03-07 2016-07-26 Communication device, control method, program, and front end
US16/380,432 US11088724B2 (en) 2012-03-07 2019-04-10 Communication device, control method, program and front end

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2012050016 2012-03-07
JP2012-050016 2012-03-07

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/382,070 A-371-Of-International US9237409B2 (en) 2012-03-07 2013-02-25 Communication device, control method, program, and front end
US14/955,582 Continuation US9444519B2 (en) 2012-03-07 2015-12-01 Communication device, control method, program, and front end

Publications (1)

Publication Number Publication Date
WO2013133058A1 true WO2013133058A1 (ja) 2013-09-12

Family

ID=49116540

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/054671 WO2013133058A1 (ja) 2012-03-07 2013-02-25 通信装置、制御方法、及びプログラム

Country Status (8)

Country Link
US (4) US9237409B2 (ja)
EP (2) EP3276537B1 (ja)
JP (3) JP6162683B2 (ja)
KR (1) KR102040348B1 (ja)
CN (1) CN104428796B (ja)
IN (1) IN2014DN07294A (ja)
MY (1) MY166919A (ja)
WO (1) WO2013133058A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3012236A1 (ja) * 2013-10-17 2015-04-24 Proton World Int Nv
WO2017038821A1 (ja) * 2015-09-04 2017-03-09 フェリカネットワークス株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JP2017182625A (ja) * 2016-03-31 2017-10-05 ブラザー工業株式会社 通信装置
JP2018512104A (ja) * 2015-02-19 2018-05-10 クゥアルコム・インコーポレイテッドQualcomm Incorporated 近傍界通信フォーラムリッスンモードプロファイル
EP2858259B1 (en) * 2013-10-07 2019-06-26 Nxp B.V. NFC tag, communication method and system

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5860631B2 (ja) * 2011-08-12 2016-02-16 フェリカネットワークス株式会社 通信装置、制御方法、及びプログラム
EP3276537B1 (en) * 2012-03-07 2019-04-24 FeliCa Networks, Inc. Communication device, control method, program, and front end
FR3018972B1 (fr) * 2014-03-18 2016-04-15 Proton World Int Nv Secure nfc routing
US10303134B2 (en) * 2015-04-10 2019-05-28 Fisher Controls International Llc Methods and apparatus for multimode RFST communications in process control systems
KR101993959B1 (ko) 2016-07-21 2019-06-27 이도훈 모바일을 이용한 통합 근거리 통신 시스템 및 그 방법
EP3617931B1 (en) * 2017-04-28 2022-07-20 Sony Group Corporation Communication device and method
EP3696759A1 (en) * 2019-02-15 2020-08-19 Nxp B.V. Method of managing priority in the context of a secure element domain with multiple interfaces, electronic device and communication system
CN110491028B (zh) * 2019-08-19 2021-09-28 马健 一种通过无线通信实现控制的智能感应取电卡及取电方法

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005223722A (ja) * 2004-02-06 2005-08-18 Matsushita Electric Ind Co Ltd 携帯端末及び車載端末
JP2009128942A (ja) * 2007-11-19 2009-06-11 Felica Networks Inc 情報処理装置、情報処理方法、及びプログラム
WO2010115770A1 (en) * 2009-04-08 2010-10-14 Gemalto Sa Method of preselecting at least one application in a mobile communication device comprising an nfc system
JP2011049778A (ja) 2009-08-26 2011-03-10 Sony Corp 情報処理装置およびプログラム
JP2011259412A (ja) * 2010-05-13 2011-12-22 Canon Inc 通信装置、通信装置の制御方法およびプログラム。

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5481140A (en) * 1992-03-10 1996-01-02 Mitsubishi Denki Kabushiki Kaisha Demand control apparatus and power distribution control system
WO2005010766A1 (ja) * 2003-07-24 2005-02-03 Fujitsu Limited データ格納システム
JP4086304B2 (ja) * 2004-04-23 2008-05-14 株式会社東芝 通信装置、通信システム、および通信制御プログラム
FR2888071A1 (fr) * 2005-06-30 2007-01-05 France Telecom Module et systeme de communication pour la mise en oeuvre d'un systeme de gestion a distance d'equipements
EP1855229B1 (fr) 2006-05-10 2010-08-11 Inside Contactless Procédé de routage de données sortantes et entrantes dans un chipset NFC
US20090037326A1 (en) * 2007-07-30 2009-02-05 Sriram Chitti Virtual Card Selector for a Portable Electronic Device
EP2221984A1 (en) * 2009-02-23 2010-08-25 Motorola, Inc. Wireless communication device for providing at least one near field communication service
JP5740102B2 (ja) 2010-04-23 2015-06-24 国立大学法人名古屋大学 細胞評価装置、インキュベータ、プログラム、培養方法、手技評価装置、および、細胞評価モデル構築装置
US9614641B2 (en) * 2010-05-12 2017-04-04 Qualcomm Incorporated Resource coordination for peer-to-peer groups through distributed negotiation
JP2012039257A (ja) * 2010-08-04 2012-02-23 Sony Corp 携帯端末、情報処理方法及びコンピュータプログラム
US8977195B2 (en) * 2011-01-06 2015-03-10 Texas Insruments Incorporated Multiple NFC card applications in multiple execution environments
CN107105007B (zh) * 2011-02-21 2020-06-12 黑莓有限公司 对等节点、对等应用服务器和存储介质
EP3276537B1 (en) * 2012-03-07 2019-04-24 FeliCa Networks, Inc. Communication device, control method, program, and front end
US9161168B2 (en) * 2013-03-15 2015-10-13 Intel Corporation Personal information communicator

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005223722A (ja) * 2004-02-06 2005-08-18 Matsushita Electric Ind Co Ltd 携帯端末及び車載端末
JP2009128942A (ja) * 2007-11-19 2009-06-11 Felica Networks Inc 情報処理装置、情報処理方法、及びプログラム
WO2010115770A1 (en) * 2009-04-08 2010-10-14 Gemalto Sa Method of preselecting at least one application in a mobile communication device comprising an nfc system
JP2011049778A (ja) 2009-08-26 2011-03-10 Sony Corp 情報処理装置およびプログラム
JP2011259412A (ja) * 2010-05-13 2011-12-22 Canon Inc 通信装置、通信装置の制御方法およびプログラム。

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2824611A4

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2858259B1 (en) * 2013-10-07 2019-06-26 Nxp B.V. NFC tag, communication method and system
FR3012236A1 (ja) * 2013-10-17 2015-04-24 Proton World Int Nv
US9838941B2 (en) 2013-10-17 2017-12-05 Proton World International N.V. NFC routing method
US9967798B2 (en) 2013-10-17 2018-05-08 Proton World lnternational N.V. NFC routing method
JP2018512104A (ja) * 2015-02-19 2018-05-10 クゥアルコム・インコーポレイテッドQualcomm Incorporated 近傍界通信フォーラムリッスンモードプロファイル
WO2017038821A1 (ja) * 2015-09-04 2017-03-09 フェリカネットワークス株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JPWO2017038821A1 (ja) * 2015-09-04 2018-06-14 フェリカネットワークス株式会社 情報処理装置、情報処理方法、プログラム、および情報処理システム
JP2017182625A (ja) * 2016-03-31 2017-10-05 ブラザー工業株式会社 通信装置

Also Published As

Publication number Publication date
EP3276537A1 (en) 2018-01-31
EP2824611A4 (en) 2015-11-25
CN104428796A (zh) 2015-03-18
KR102040348B1 (ko) 2019-11-04
US9444519B2 (en) 2016-09-13
US20150038077A1 (en) 2015-02-05
US10305547B2 (en) 2019-05-28
MY166919A (en) 2018-07-24
US20190238187A1 (en) 2019-08-01
EP3276537B1 (en) 2019-04-24
US20160087683A1 (en) 2016-03-24
JPWO2013133058A1 (ja) 2015-07-30
IN2014DN07294A (ja) 2015-04-24
EP2824611A1 (en) 2015-01-14
US20160337002A1 (en) 2016-11-17
JP6162683B2 (ja) 2017-07-19
KR20140141584A (ko) 2014-12-10
JP2017201544A (ja) 2017-11-09
JP6792315B2 (ja) 2020-11-25
JP2019083026A (ja) 2019-05-30
EP2824611B1 (en) 2017-10-11
US11088724B2 (en) 2021-08-10
US9237409B2 (en) 2016-01-12
JP6461242B2 (ja) 2019-01-30
CN104428796B (zh) 2017-09-01

Similar Documents

Publication Publication Date Title
JP6461242B2 (ja) 通信装置
US9907091B2 (en) Communication device, control method, and program
EP2563046B1 (en) Terminal, system, and method for retrieving an application
CN103503323B (zh) 近场通信射频通信方法、装置和终端设备
US20140176306A1 (en) Near-field-communication (nfc) enabled mobile device and operation method thereof
EP3155554B1 (en) Electronic device, system and method for nfc
US20170169263A1 (en) Systems and methods for a cloud connected transponder
EP2680657B1 (en) Emulation of multiple nfc devices inside a communication device
CN107636982A (zh) 数据帧路由处理的方法、近场通信控制器和终端
US9547781B2 (en) Method for recognizing tag in environment using same frequency band and NFC device for the same
CN113170376A (zh) 接近装置网络
US10225703B2 (en) Communication circuit, communication apparatus, communication method and computer program for acquiring available services in an active communication mode and a passive communication mode using NFC
Park et al. Fast object identification with mode switching for coexistence of NFC and RFID
CN109195142B (zh) 一种移动终端nfc数据传输检测方法、移动终端及存储介质
KR101717231B1 (ko) Nfc 장치와 rfid 시스템이 공존하는 환경에서 nfc 장치간 p2p 통신을 고려한 충돌 방지 방법 및 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13758604

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2014503767

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2013758604

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2013758604

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 20147024308

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: IDP00201405190

Country of ref document: ID

Ref document number: 14382070

Country of ref document: US