WO2023214643A1 - 세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법 - Google Patents

세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법 Download PDF

Info

Publication number
WO2023214643A1
WO2023214643A1 PCT/KR2023/001481 KR2023001481W WO2023214643A1 WO 2023214643 A1 WO2023214643 A1 WO 2023214643A1 KR 2023001481 W KR2023001481 W KR 2023001481W WO 2023214643 A1 WO2023214643 A1 WO 2023214643A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
sip
call
message
electronic device
Prior art date
Application number
PCT/KR2023/001481
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 US18/171,054 priority Critical patent/US20230353565A1/en
Publication of WO2023214643A1 publication Critical patent/WO2023214643A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/436—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/436—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it
    • H04M3/4365—Arrangements for screening incoming calls, i.e. evaluating the characteristics of a call before deciding whether to answer it based on information specified by the calling party, e.g. priority or subject

Definitions

  • This disclosure relates to session initiation protocol (SIP). More specifically, the present disclosure relates to an apparatus and method for authentication in SIP.
  • SIP session initiation protocol
  • Session initial protocol is a signaling protocol for managing sessions or calls in multimedia communication.
  • the caller and callee can establish a call through the request and response of the SIP protocol. Meanwhile, the sender can make a private call to the recipient. If call forwarding is set up on the recipient's electronic device, or if the recipient's electronic device is under the control of someone other than the recipient, the caller may not want the call to connect.
  • a method performed by an electronic device may include transmitting a session initiation protocol (SIP) INVITE message for a session connection request to another electronic device through a server.
  • the SIP INVITE message may include information indicating an authentication request.
  • the method may include receiving a SIP information message indicating ringing from the other electronic device through the server.
  • the SIP information message to indicate the ringing may include information indicating authentication support.
  • the method may include an operation of identifying whether a SIP response message indicating success of the connection request is received from the other electronic device or the electronic device subject to call forwarding. .
  • the method may include establishing the session in response to receiving the SIP response message. Reception of the SIP response message may indicate successful authentication in the other electronic device or the target electronic device according to the authentication request.
  • a method performed by an electronic device may include receiving a session initiation protocol (SIP) INVITE message for a session connection request from another electronic device through a server.
  • the SIP INVITE message may include an authentication request.
  • the method may include transmitting a SIP information message indicating ringing to the other electronic device through the server.
  • the SIP information message to indicate the ringing may include authentication support.
  • the method may include receiving a designated user input according to the authentication request.
  • the method may include transmitting a SIP response message to indicate success of the connection request to the other electronic device based on the specified user input.
  • an electronic device includes: memory; at least one transceiver; and at least one processor coupled to the memory and the at least one transceiver.
  • the at least one processor may be configured to transmit a session initiation protocol (SIP) invitation (INVITE) message for a session connection request to another electronic device through a server.
  • the SIP INVITE message may include information indicating an authentication request.
  • the at least one processor may be configured to receive a SIP information message indicating ringing from the other electronic device through the server.
  • the SIP information message to indicate the ringing may include information indicating authentication support.
  • the at least one processor may identify whether a SIP response message indicating success of the connection request is received from the other electronic device or the electronic device subject to call forwarding. .
  • the at least one processor may be configured to establish the session in response to receiving the SIP response message. Reception of the SIP response message may indicate successful authentication in the other electronic device or the target electronic device according to the authentication request.
  • an electronic device includes: memory; at least one transceiver; and at least one processor coupled to the memory and the at least one transceiver.
  • the at least one processor may be configured to receive a session initiation protocol (SIP) invitation (INVITE) message for a session connection request from another electronic device through a server.
  • the SIP INVITE message may include an authentication request.
  • the at least one processor may be configured to transmit a SIP information message indicating ringing to the other electronic device through the server.
  • the SIP information message to indicate the ringing may include authentication support.
  • the at least one processor may be configured to receive a designated user input according to the authentication request.
  • the at least one processor may be configured to transmit a SIP response message indicating success of the connection request to the other electronic device based on the specified user input.
  • FIG. 1 is a block diagram of an electronic device in a network environment, according to an embodiment of the present disclosure.
  • Figure 2 shows an example of an incoming call from a called callee according to an embodiment of the present disclosure.
  • FIG. 3 shows an example of signaling for a call connection requesting recipient authentication in session initiation protocol (SIP), according to an embodiment of the present disclosure.
  • SIP session initiation protocol
  • Figure 4 shows another example of signaling for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • Figure 5 shows an example of a server for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • FIG. 6 illustrates an operation flow of a caller device for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • FIG. 7 illustrates an operation flow of a recipient device for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • Figure 8 shows an example of a user interface (UI) for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • UI user interface
  • FIG. 9A shows the operation flow of a caller device for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • FIG. 9B illustrates the operation flow of a recipient device for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • Figure 10a shows the operation flow of a caller device for an authentication procedure when forwarding a call in SIP, according to an embodiment of the present disclosure.
  • Figure 10b shows the operation flow of a recipient device for an authentication procedure when forwarding a call in SIP, according to an embodiment of the present disclosure.
  • Figure 11A shows the operational flow of a sender device for an authentication procedure using capability information in SIP, according to an embodiment of the present disclosure.
  • Figure 11b shows the operational flow of a recipient device for an authentication procedure using capability information in SIP, according to an embodiment of the present disclosure.
  • Figure 12 shows an example of signaling for an authentication procedure using a server in SIP, according to an embodiment of the present disclosure.
  • Figure 13 shows the operation flow of a recipient device for sender request-based authentication using a timer, according to an embodiment of the present disclosure.
  • FIG. 14A illustrates an operational flow of a sender device for sender demand-based authentication using a passcode, according to an embodiment of the present disclosure.
  • FIG. 14B shows an operational flow of a recipient device for sender demand-based authentication using a password, according to an embodiment of the present disclosure.
  • FIG. 15 illustrates the operation flow of a sender device and a receiver device for sender request-based authentication according to screen lock, according to an embodiment of the present disclosure.
  • Signal e.g. signal, information, message, signaling
  • terms referring to resources, and terms for connection status used in the following description e.g. call, call, session
  • terms for operational states e.g. step, operation, procedure
  • terms referring to data e.g. packet, user stream, information, bit, symbol
  • symbols, codeword symbols referring to channels
  • terms referring to network entities, terms referring to device components, etc. are exemplified for convenience of explanation. Accordingly, the present disclosure is not limited to the terms described below, and other terms having equivalent technical meaning may be used.
  • the expressions greater than or less than may be used to determine whether a specific condition is satisfied or fulfilled, but this is only a description for expressing an example, and the description of more or less may be used. It's not exclusion. Conditions written as ‘more than’ can be replaced with ‘more than’, conditions written as ‘less than’ can be replaced with ‘less than’, and conditions written as ‘more than and less than’ can be replaced with ‘greater than and less than’.
  • the present disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), extensible radio access network (xRAN), and open-radio access network (O-RAN))
  • 3GPP 3rd Generation Partnership Project
  • xRAN extensible radio access network
  • OF-RAN open-radio access network
  • FIG. 1 is a block diagram of an electronic device in a network environment, according to an embodiment of the present disclosure.
  • the electronic device 101 communicates with the electronic device 102 through a first network 198 (e.g., a short-range wireless communication network) or a second network 199. It is possible to communicate with at least one of the electronic device 104 or the server 108 through (e.g., a long-distance wireless communication network). According to one embodiment, the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • a first network 198 e.g., a short-range wireless communication network
  • a second network 199 e.g., a long-distance wireless communication network.
  • the electronic device 101 may communicate with the electronic device 104 through the server 108.
  • the electronic device 101 includes a processor 120, a memory 130, an input module 150, an audio output module 155, a display module 160, an audio module 170, and a sensor module ( 176), interface 177, connection terminal 178, haptic module 179, camera module 180, power management module 188, battery 189, communication module 190, subscriber identification module 196 , or may include an antenna module 197.
  • at least one of these components eg, the connection terminal 178) may be omitted or one or more other components may be added to the electronic device 101.
  • some of these components e.g., sensor module 176, camera module 180, or antenna module 197) are integrated into one component (e.g., display module 160). It can be.
  • the processor 120 executes software (e.g., program 140) to control at least one other component (e.g., hardware or software component) of the electronic device 101 connected to the processor 120. and perform various data processing or calculations.
  • the processor 120 may include other components (e.g., a sensor module 176 or a communication module ( The command or data received from 190) may be stored in the volatile memory 132, the command or data stored in the volatile memory 132 may be processed, and the resulting data may be stored in the non-volatile memory 134.
  • the main processor 121 e.g., a central processing unit or an application processor
  • an auxiliary processor 123 that can operate independently or together (e.g., a graphics processing unit, a neural network processing unit (NPU) processing unit), an image signal processor, a sensor hub processor, or a communication processor).
  • the electronic device 101 includes a main processor 121 and an auxiliary processor 123
  • the auxiliary processor 123 may be set to use less power than the main processor 121 or be specialized for a designated function.
  • the auxiliary processor 123 may be implemented separately from the main processor 121 or as a part of it.
  • the auxiliary processor 123 may, for example, act on behalf of the main processor 121 while the main processor 121 is in an inactive (e.g., sleep) state, or while the main processor 121 is in an active (e.g., application execution) state. ), together with the main processor 121, at least one of the components of the electronic device 101 (e.g., the display module 160, the sensor module 176, or the communication module 190) At least some of the functions or states related to can be controlled.
  • co-processor 123 e.g., image signal processor or communication processor
  • may be implemented as part of another functionally related component e.g., camera module 180 or communication module 190. there is.
  • the auxiliary processor 123 may include a hardware structure specialized for processing artificial intelligence models.
  • Artificial intelligence models can be created through machine learning. For example, such learning may be performed in the electronic device 101 itself on which the artificial intelligence model is performed, or may be performed through a separate server (e.g., server 108).
  • Learning algorithms may include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but It is not limited.
  • An artificial intelligence model may include multiple artificial neural network layers.
  • Artificial neural networks include deep neural network (DNN), convolutional neural network (CNN), recurrent neural network (RNN), restricted boltzmann machine (RBM), belief deep network (DBN), bidirectional recurrent deep neural network (BRDNN), It may be one of deep Q-networks or a combination of two or more of the above, but is not limited to the examples described above.
  • artificial intelligence models may additionally or alternatively include software structures.
  • the memory 130 may store various data used by at least one component (eg, the processor 120 or the sensor module 176) of the electronic device 101. Data may include, for example, input data or output data for software (e.g., program 140) and instructions related thereto.
  • Memory 130 may include volatile memory 132 or non-volatile memory 134. ) may include.
  • the program 140 may be stored as software in the memory 130 and may include, for example, an operating system 142, middleware 144, or application 146.
  • the input module 150 may receive commands or data to be used in a component of the electronic device 101 (e.g., the processor 120) from outside the electronic device 101 (e.g., a user).
  • the input module 150 may include, for example, a microphone, mouse, keyboard, keys (eg, buttons), or digital pen (eg, stylus pen).
  • the sound output module 155 may output sound signals to the outside of the electronic device 101.
  • the sound output module 155 may include, for example, a speaker or a receiver. Speakers can be used for general purposes such as multimedia playback or recording playback.
  • the receiver can be used to receive incoming calls. According to one embodiment, the receiver may be implemented separately from the speaker or as part of it.
  • the display module 160 can visually provide information to the outside of the electronic device 101 (eg, a user).
  • the display module 160 may include, for example, a display, a hologram device, or a projector, and a control circuit for controlling the device.
  • the display module 160 may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of force generated by the touch.
  • the audio module 170 can convert sound into an electrical signal or, conversely, convert an electrical signal into sound. According to one embodiment, the audio module 170 acquires sound through the input module 150, the sound output module 155, or an external electronic device (e.g., directly or wirelessly connected to the electronic device 101). Sound may be output through the electronic device 102 (e.g., speaker or headphone).
  • the electronic device 102 e.g., speaker or headphone
  • the sensor module 176 detects the operating state (e.g., power or temperature) of the electronic device 101 or the external environmental state (e.g., user state) and generates an electrical signal or data value corresponding to the detected state. can do.
  • the sensor module 176 includes, for example, a gesture sensor, a gyro sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, It may include a temperature sensor, humidity sensor, or light sensor.
  • the interface 177 may support one or more designated protocols that can be used to connect the electronic device 101 directly or wirelessly with an external electronic device (eg, the electronic device 102).
  • the interface 177 may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.
  • HDMI high definition multimedia interface
  • USB universal serial bus
  • SD card interface Secure Digital Card interface
  • audio interface audio interface
  • connection terminal 178 may include a connector through which the electronic device 101 can be physically connected to an external electronic device (eg, the electronic device 102).
  • the connection terminal 178 may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (eg, a headphone connector).
  • the haptic module 179 can convert electrical signals into mechanical stimulation (e.g., vibration or movement) or electrical stimulation that the user can perceive through tactile or kinesthetic senses.
  • the haptic module 179 may include, for example, a motor, a piezoelectric element, or an electrical stimulation device.
  • the camera module 180 can capture still images and moving images.
  • the camera module 180 may include one or more lenses, image sensors, image signal processors, or flashes.
  • the power management module 188 can manage power supplied to the electronic device 101.
  • the power management module 188 may be implemented as at least a part of, for example, a power management integrated circuit (PMIC).
  • PMIC power management integrated circuit
  • the battery 189 may supply power to at least one component of the electronic device 101.
  • the battery 189 may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.
  • Communication module 190 is configured to provide a direct (e.g., wired) communication channel or wireless communication channel between electronic device 101 and an external electronic device (e.g., electronic device 102, electronic device 104, or server 108). It can support establishment and communication through established communication channels. Communication module 190 operates independently of processor 120 (e.g., an application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication.
  • processor 120 e.g., an application processor
  • the communication module 190 may be a wireless communication module 192 (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module 194 (e.g., : LAN (local area network) communication module, or power line communication module) may be included.
  • a wireless communication module 192 e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module
  • GNSS global navigation satellite system
  • wired communication module 194 e.g., : LAN (local area network) communication module, or power line communication module
  • the corresponding communication module is a first network 198 (e.g., a short-range communication network such as Bluetooth, wireless fidelity (WiFi) direct, or infrared data association (IrDA)) or a second network 199 (e.g., legacy It may communicate with an external electronic device 104 through a telecommunication network such as a cellular network, a 5th generation (5G) network, a next-generation communication network, the Internet, or a computer network (e.g., LAN or WAN).
  • a telecommunication network such as a cellular network, a 5th generation (5G) network, a next-generation communication network, the Internet, or a computer network (e.g., LAN or WAN).
  • 5G 5th generation
  • next-generation communication network e.g., the Internet
  • a computer network e.g., LAN or WAN
  • the wireless communication module 192 uses subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module 196 to communicate within a communication network such as the first network 198 or the second network 199.
  • subscriber information e.g., International Mobile Subscriber Identifier (IMSI)
  • IMSI International Mobile Subscriber Identifier
  • the wireless communication module 192 may support a 5G network and next-generation communication technology after the 4th generation (4G) network, for example, new radio access technology (NR access technology).
  • NR access technology can provide high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and access to multiple terminals (massive machine type communications (mMTC)), or ultra-reliable and low-latency (URLLC). -latency communications)) can be supported.
  • eMBB enhanced mobile broadband
  • mMTC massive machine type communications
  • URLLC ultra-reliable and low-latency communications
  • the wireless communication module 192 may support a high frequency band (eg, mmWave band), for example, to achieve a high data transmission rate.
  • the wireless communication module 192 uses various technologies to secure performance in high frequency bands, for example, beamforming, massive array multiple-input and multiple-output (MIMO), and full-dimensional multiplexing. It can support technologies such as input/output (FD-MIMO: full dimensional MIMO), array antenna, analog beam-forming, or large scale antenna.
  • the wireless communication module 192 may support various requirements specified in the electronic device 101, an external electronic device (e.g., electronic device 104), or a network system (e.g., second network 199).
  • the wireless communication module 192 supports Peak data rate (e.g., 20 Gbps or more) for realizing eMBB, loss coverage (e.g., 164 dB or less) for realizing mmTC, or U-plane latency (e.g., 164 dB or less) for realizing URLLC.
  • Peak data rate e.g., 20 Gbps or more
  • loss coverage e.g., 164 dB or less
  • U-plane latency e.g., 164 dB or less
  • the antenna module 197 may transmit or receive signals or power to or from the outside (eg, an external electronic device).
  • the antenna module 197 may include an antenna including a radiator made of a conductor or a conductive pattern formed on a substrate (eg, PCB).
  • the antenna module 197 may include a plurality of antennas (eg, an array antenna). In this case, at least one antenna suitable for the communication method used in the communication network, such as the first network 198 or the second network 199, is connected to the plurality of antennas by, for example, the communication module 190. can be selected Signals or power may be transmitted or received between the communication module 190 and an external electronic device through the at least one selected antenna.
  • other components eg, radio frequency integrated circuit (RFIC) may be additionally formed as part of the antenna module 197.
  • RFIC radio frequency integrated circuit
  • the antenna module 197 may form a mmWave antenna module.
  • a mmWave antenna module includes a printed circuit board, an RFIC disposed on or adjacent to a first side (e.g., bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., mmWave band); And a plurality of antennas (e.g., array antennas) disposed on or adjacent to the second side (e.g., top or side) of the printed circuit board and capable of transmitting or receiving signals in the designated high frequency band. can do.
  • a mmWave antenna module includes a printed circuit board, an RFIC disposed on or adjacent to a first side (e.g., bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., mmWave band); And a plurality of antennas (e.g., array antennas) disposed on or adjacent to the second side (e.g., top or side)
  • peripheral devices e.g., bus, general purpose input and output (GPIO), serial peripheral interface (SPI), or mobile industry processor interface (MIPI)
  • signal e.g. commands or data
  • commands or data may be transmitted or received between the electronic device 101 and the external electronic device 104 through the server 108 connected to the second network 199.
  • Each of the external electronic devices 102 or 104 may be of the same or different type as the electronic device 101.
  • all or part of the operations performed in the electronic device 101 may be executed in one or more of the external electronic devices 102, 104, or 108.
  • the electronic device 101 may perform the function or service instead of executing the function or service on its own.
  • one or more external electronic devices may be requested to perform at least part of the function or service.
  • One or more external electronic devices that have received the request may execute at least part of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device 101.
  • the electronic device 101 may process the result as is or additionally and provide it as at least part of a response to the request.
  • cloud computing distributed computing, mobile edge computing (MEC), or client-server computing technology can be used.
  • the electronic device 101 may provide an ultra-low latency service using, for example, distributed computing or mobile edge computing.
  • the external electronic device 104 may include an Internet of Things (IoT) device.
  • Server 108 may be an intelligent server using machine learning and/or neural networks.
  • the external electronic device 104 or server 108 may be included in the second network 199.
  • the electronic device 101 may be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.
  • Embodiments of the present disclosure propose a technology for performing authentication of the called party according to the caller's demand during session establishment, such as in a situation where the caller (caller) calls the called party (callee). .
  • the caller calls the called party (callee).
  • the privacy of the sender can be protected and a telephone service useful for security calls can be provided.
  • Figure 2 shows an example of an incoming call from a called callee according to an embodiment of the present disclosure.
  • the situation in which the sender calls the recipient is described as an example.
  • the recipient's electronic device may be referred to as a recipient device, and the sender's electronic device may be referred to as a sender device.
  • the recipient device and the sender device illustrate the electronic device 101.
  • the screen of the recipient device when a call is received, the screen of the recipient device may be switched from the first state 201 to the second state 203. Thereafter, when a call acceptance input is received from the recipient device, the screen of the recipient device may be switched from the second state 203 to the third state 205.
  • the recipient device may provide a user interface (UI)/user experience (UX) to the user to inquire about call acceptance.
  • the user can accept the call through an acceptance input (e.g., clicking or swiping an object indicating acceptance) without a separate authentication process.
  • the called device may establish a session in response to receiving a call acceptance input.
  • call activity is displayed on the screen regardless of whether the recipient device is locked, so anyone can unlock the phone or answer the call even if they are not the owner of the recipient device. That is, even if a lock is set on the recipient device, a session can be established without going through an authentication step to unlock the lock.
  • embodiments of the present disclosure propose an apparatus and method for performing an authentication procedure according to the demand of a caller. Additionally, embodiments of the present disclosure propose an apparatus and method for solving the problem of OTP-related calls or sensitive calls being forwarded to another device. Additionally, embodiments of the present disclosure propose an apparatus and method for adaptively requesting an authentication procedure according to authentication requirements set by the caller, instead of requiring an authentication procedure for all calls.
  • SIP session initiation protocol
  • SIP controls sessions to enable circuit-switched network call control in a packet-switched network.
  • SIP enables multimedia applications on the Internet of packet networks.
  • SIP uses a text-based addressing method in the form of URL (uniform resource locator) and E-mail.
  • URL uniform resource locator
  • SIP clients and SIP servers are defined.
  • SIP clients may include user agent client (UAC) and user agent server (UAS).
  • UAC is located at the end of the session and can create calls and request settings.
  • the UAS can accept, reject, or redirect the call from the UAC.
  • the sender device and the receiver device of the present disclosure may refer to UAS, and the server may refer to UAS.
  • the SIP server may include a proxy server, a register server, a redirect server, and a location server. Through a SIP server, scalability of session connections can be provided.
  • a request message and a response message are defined.
  • SIP Session Initiation Protocol, a transaction including a request and response is required to connect a call.
  • a SIP request may include INVITE, acknowledgment (ACK), BYE, CANCEL, OPTIONS, and REGISTER.
  • the SIP INVITE message can be used to join a multimedia session.
  • the SIP ACK message can be used to notify that a 200 OK response has been received.
  • the SIP BYE message can be used to terminate the session.
  • the SIP CANCEL message can be used to cancel an existing request before receiving a 200 OK response.
  • the SIP OPTIONS message can be used to request capabilities from the server.
  • SIP REGISTER can be used to register a user device (e.g. user agent (UA)) with a registration server.
  • UA user agent
  • SIP responses may include information messages, success messages, redirect messages, error messages, and failure messages.
  • the information message corresponds to a response code of '1xx' and can be notified when the time to process the request before the final response is more than 200ms.
  • an information message with a response code of '100' indicates 'Trying' and indicates that the received request is being sent to the next server or is being processed.
  • an information message with a response code of '180' indicates 'Ringing' and indicates that the recipient device is ringing.
  • the sender device receives an information message with a response code of '180', it can play a ring-back tone or prepare to receive a ring-back tone.
  • an information message with a response code of '181' indicates 'Call is Being Forwarded' and indicates that the call forwarding function is set on the recipient device. Notifies that a call is being attempted to the device subject to call forwarding.
  • the success message corresponds to a response code of '2xx' and indicates that the request was processed normally.
  • an information message with a response code of '200' indicates 'OK' and indicates that the request has been processed successfully.
  • An informational message with a response code of '202' indicates 'Accepted' and indicates that the request has been approved for processing but is still being processed.
  • the redirection message corresponds to a response code of '3xx' and indicates that the user is moving to a new location or that UA (user agent) information is being integrated into a changed service.
  • the error message may include a message according to an error in the sender device corresponding to a response code of '4xx' and a message due to an error in the server corresponding to a response code of '5xx'.
  • the error message indicates that the request failed.
  • the failure message corresponds to a response code of '6xx' and notifies failure information about the recipient (e.g., the recipient's status is not answering the phone).
  • FIG 3 shows an example of signaling for authentication according to a caller's demand in session initiation protocol (SIP), according to an embodiment of the present disclosure.
  • the recipient's electronic device is a mobile termination (MT) and may be referred to as a recipient device.
  • the sender's electronic device is a mobile originator (MO) and may be referred to as a sender device.
  • the recipient device and the sender device illustrate the electronic device 101.
  • the sender device 310 may transmit a SIP INVITE message to the network device 320.
  • the sender device 310 may make a call to the recipient device 330 through the network device 320 (eg, a server).
  • the sender device 310 may decide to make a call to the recipient device 330 that includes an authentication request according to the caller's request.
  • Sender device 310 may generate a SIP INVITE message containing an authentication request.
  • the sender device 310 may transmit a SIP INVITE message including an authentication flag to the recipient device 330.
  • a user of calling device 310 may, through specified input, generate a SIP INVITE message to place a call that includes an authentication request.
  • the SIP INVITE message may indicate an authentication request.
  • the call information (Call-info) field of the header of the SIP INVITE message may include information indicating an authentication request.
  • the network device 320 may transmit a SIP INVITE message to the recipient device 330.
  • the SIP INVITE message may indicate an authentication request.
  • the call information (Call-info) field of the header of the SIP INVITE message may include information indicating an authentication request.
  • the recipient device 330 may transmit a SIP response message to the network device 320.
  • the recipient device 330 can process the SIP INVITE message.
  • Recipient device 330 may respond to sender device 310 to indicate authentication support.
  • Recipient device 330 may generate a SIP response message indicating authentication support.
  • the SIP response message may indicate ringing of the recipient device 330.
  • the code number of the SIP response message may be 180.
  • the call information (Call-info) field of the header of the SIP response message may include information indicating authentication support.
  • the network device 320 may transmit a SIP response message to the sender device 310.
  • the SIP response message may indicate ringing of the recipient device 330.
  • the code number of the SIP response message may be 180.
  • the SIP response message may include information indicating that recipient authentication according to the sender's request is supported.
  • the call information (Call-info) field of the header of the SIP response message may include information indicating authentication support.
  • the recipient device 330 may transmit a SIP response message to the network device 320.
  • recipient device 330 may identify an authentication method. For example, user settings for authentication may include entering a pattern. As another example, user settings for authentication may include a password. As another example, user settings for authentication may include fingerprint recognition. As another example, user settings for authentication may include iris recognition.
  • the recipient device 330 may identify whether authentication is successful based on user settings. For example, the recipient device 330 may identify successful authentication if the received fingerprint input is identical to the fingerprint information stored in the recipient device 330. For example, the recipient device 330 may identify successful authentication if the received password input is the same as the password information stored in the recipient device 330. For example, the recipient device 330 may identify successful authentication if the received iris input is the same as the iris information stored in the recipient device 330. For example, the recipient device 330 may identify successful authentication if the received pattern input is the same as the pattern information stored in the recipient device 330. Recipient device 330 may generate a SIP response message indicating successful connection based on identifying successful authentication.
  • the recipient device 330 may continue to ring.
  • the recipient device 330 may repeatedly transmit a SIP response message corresponding to '180 Ringing' to the sender device 310.
  • the recipient device 330 may repeatedly request authentication from the user to retry the authentication process.
  • a time limit for retry may be set.
  • the step of requesting authentication from the user may be performed sequentially with the step of determining whether to accept or reject the call.
  • the recipient device 330 may request authentication from the user when an acceptance input from a phone call is received.
  • the recipient device 330 may display a UI requesting authentication input from the user.
  • authentication may be requested from the user. That is, the recipient device 330 may request user authentication for both acceptance and rejection of the call.
  • authentication is to confirm that the subject providing the input is the owner of the recipient device 330.
  • the recipient device 330 may request authentication from the user before requesting an acceptance or rejection input for the call.
  • the recipient device 330 may request authentication from the user. Thereafter, when the user's authentication is completed, the recipient device 330 may display a UI for inquiring about an acceptance or rejection input of the phone.
  • the recipient device 330 may generate a SIP response message.
  • the SIP response message can be transmitted from the recipient device 330 when recipient authentication according to the sender's request is completed.
  • the SIP response message may indicate success of the connection request.
  • the code number of the SIP response message may be 200.
  • the network device 320 may transmit a SIP response message to the sender device 310.
  • the SIP response message may indicate success of the connection request.
  • the code number of the SIP response message may be 200.
  • the sender device 310 may identify that user authentication has been completed in the recipient device 330.
  • the sender device 310 may establish a media session with the recipient device 330. Thereafter, the sender device 310 and the recipient device 330 may exchange data packets through the established media session. For example, the sender device 310 and the recipient device 330 may perform a Voice over Internet Protocol (VoIP) call.
  • VoIP Voice over Internet Protocol
  • the sender device 310 may transmit a SIP request message to the network device 320.
  • the SIP request message may indicate termination of the call at the calling party device 310.
  • the network device 320 may transmit a SIP request message to the recipient device 330.
  • the recipient device 330 may identify that the sender device 310 has requested termination of the call.
  • the recipient device 330 may transmit a SIP response message to the network device 320.
  • the SIP response message may indicate success of the termination request.
  • the code number of the SIP response message may be 200.
  • the network device 320 may transmit a SIP response message to the sender device 310.
  • the SIP response message may indicate success of the termination request.
  • the code number of the SIP response message may be 200.
  • termination of the call is initiated by the sender device 310, but of course, termination of the call may be initiated by the recipient device 330.
  • Figure 4 shows another example of signaling for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • the recipient's electronic device is a mobile termination (MT) and may be referred to as a recipient device.
  • the sender's electronic device is a mobile originator (MO) and may be referred to as a sender device.
  • the recipient device and the sender device illustrate the electronic device 101.
  • a call processing method is described when the recipient device does not support the authentication function according to the caller's request or when the recipient device does not have security settings.
  • the sender device 410 may transmit a SIP INVITE message to the network device 420.
  • the sender device 410 may make a call to the recipient device 430 through the network device 420 (eg, a server).
  • the sender device 410 may generate a SIP INVITE message including an authentication request according to the sender's request to the receiver device 430.
  • Operation S401 corresponds to operation S301 of FIG. 3, and the explanation described in operation S301 of FIG. 3 is applied to the sender device 410, the network device 420, and the recipient device 430 in the same way. It can be applied.
  • the network device 420 may transmit a SIP INVITE message to the recipient device 430.
  • Operation S403 corresponds to operation S303 of FIG. 3, and the explanation described in operation S303 of FIG. 3 is applied to the sender device 410, the network device 420, and the recipient device 430 in the same manner. It can be applied.
  • the recipient device 430 may transmit a SIP response message to the network device 420.
  • the recipient device 430 can process the SIP INVITE message.
  • the recipient device 430 may transmit a response message that does not include authentication status.
  • the recipient device 430 may generate a SIP response message without authentication status if the recipient device 430 does not support the authentication function according to the sender's request or does not have security settings (e.g., settings for unlocking the screen lock). You can. This is because the authentication status cannot be defined.
  • the call information (Call-info) field of the header of the SIP response message may be set to not include any information.
  • the network device 420 may transmit a SIP response message to the sender device 410.
  • the SIP response message may indicate ringing of the recipient device 430.
  • the code number of the SIP response message may be 180.
  • the call information (Call-info) field of the header of the SIP response message may be set to not include any information.
  • Sender device 410 may receive a response message that does not include authentication status. If the recipient device 430 does not support the authentication function before establishing a session or an authentication method is not set in the recipient device 430, the sender device 410 allows the user to perform call processing such as maintaining or ending the call. . According to one embodiment, the caller device 410 may display a UI for inquiring about maintaining or ending the call to the user of the caller device 410. Depending on the input received by the sender device 410, the sender device 410 may wait for a SIP response message indicating '200 OK' or transmit a SIP request message indicating 'BYE'. According to another embodiment, the caller device 410 may maintain or end the call according to user settings.
  • the caller device 410 may display on the screen of the caller device 410 that the call has changed from a secure phone call to a regular phone call.
  • the caller device 410 may transmit a SIP request message indicating 'BYE'.
  • User settings may be predefined in the settings menu of the caller device 410 or entered in the UI during a call.
  • the sender device 410 may wait for a SIP response message indicating '200 OK'.
  • Sender device 410 may perform a follow-up procedure 440.
  • the recipient device 430 may transmit a SIP response message to the network device 420.
  • the SIP response message may indicate success of the connection request.
  • the recipient device 430 may display a UI for inquiring about acceptance or rejection of a call without requiring authentication.
  • the recipient device 430 may generate a SIP response message.
  • the recipient device 430 may generate a SIP response message notifying the call rejection.
  • the network device 420 may transmit a SIP response message to the sender device 410.
  • the SIP response message may indicate success of the connection request.
  • the code number of the SIP response message may be 200.
  • the sender device 410 may identify that user authentication has been completed in the recipient device 430.
  • the sender device 410 may establish a media session with the recipient device 430. Thereafter, the sender device 410 and the recipient device 430 can exchange data packets through the established media session. For example, the sender device 410 and the recipient device 430 may perform a Voice over Internet Protocol (VoIP) call.
  • VoIP Voice over Internet Protocol
  • the sender device 410 may transmit a SIP request message to the network device 420.
  • the SIP request message may indicate termination of the call at the calling party device 410.
  • the network device 420 may transmit a SIP request message to the recipient device 430.
  • the recipient device 430 may identify that the sender device 410 has requested termination of the call.
  • the recipient device 430 may transmit a SIP response message to the network device 420.
  • the SIP response message may indicate success of the termination request.
  • the code number of the SIP response message may be 200.
  • the network device 420 may transmit a SIP response message to the sender device 410.
  • the SIP response message may indicate success of the termination request.
  • the code number of the SIP response message may be 200.
  • termination of the call is initiated by the sender device 410, but of course, termination of the call may be initiated by the recipient device 430.
  • Figure 5 shows an example of a server for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • the recipient authentication process according to the sender's request can be performed in combination with call forwarding.
  • management of authentication setting status may be performed by a server.
  • the server may include an Internet Protocol (IP) Multimedia Subsystem (IMS) server 521.
  • the server may include an account management server (eg, a computer-mediated communication (CMC) server, a rich communication service (RCS) server) of a business operator or OEM.
  • selection of a target electronic device for call forwarding may be performed by the recipient device or by a network entity in the network.
  • the account management server 522 may be introduced into the authentication process.
  • the secure call may require authentication of the first recipient device 531. If the first recipient device 531 does not support authentication or there is no authentication setting, the secure call may be forwarded to the second recipient device 532, which is the next recipient device.
  • the next recipient device refers to the target electronic device set for call forwarding. Call forwarding may be performed through the account management server 522. The operations of the recipient device described through FIGS. 3 and 4 may be applied to the next recipient device (eg, the second recipient device 532) in the same manner.
  • the second recipient device 532 may perform recipient authentication according to the sender's request.
  • the second recipient device 532 may transmit a SIP response message to the sender device 530 through the IMS server 521.
  • the second recipient device 532 may transmit a SIP response message to indicate that authentication of the second recipient device 532 has been completed.
  • the SIP response message may include '200 OK' indicating success of the request.
  • the second recipient device 532 may transmit a SIP response message indicating authentication support instead of the first recipient device 531.
  • the code of the SIP response message indicating authentication support may indicate '180 Ringing'.
  • the second recipient device 532 may send a SIP response message indicating authentication support before the SIP response message indicating success of the request.
  • the calling device 510 can determine whether to maintain the call request to the second recipient device 532 or terminate the call request. This is because the user of the calling device 510 may not want to make a secure call with the second called device 532.
  • call forwarding may be set in the second recipient device 532. If the user of the second recipient device 532 does not answer, the secure call may be forwarded to the third recipient device 533.
  • the description of the operation of the second recipient device 532 after call forwarding can be applied to the third recipient device 533 in the same way.
  • the call may be configured to be accepted only from authenticated devices. Accordingly, the privacy of the sender device 510 can be protected and the reliability of a secure call between the sender and receiver can be increased.
  • FIG. 6 illustrates an operation flow of a caller device for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • the originating device may transmit a SIP INVITE message containing an authentication request.
  • the calling device may decide to initiate a secure call with the called device.
  • a calling device may decide to initiate a secure call with the called device based on a user's input to indicate a secure call. For example, as shown in Figure 8, as a touch input is received on an object indicating a secure call, the originating device may determine to initiate a secure call with the called device.
  • the originating device may decide to initiate a secure call with the recipient device based on predefined settings for the recipient device. For example, a calling device may decide to initiate a secure call with a called device based on identifying the called device as being included in a predefined group.
  • the sender device may generate a SIP INVITE message containing an authentication request.
  • the sender device can set an authentication flag in the SIP INVITE message.
  • the sender device may set an authentication flag in the header field of the SIP INVITE message.
  • the sender device can create a SIP INVITE message so that the 'Call-info' field of the SIP INVITE message indicates an authentication request.
  • the originating device may receive a SIP information message to indicate authentication support.
  • the code of the SIP information message may indicate '181 Ringing'.
  • the recipient device may transmit a SIP information message to inform the sender device that the recipient device may request authentication from the user according to the sender request. This is because if the recipient device cannot provide the user with an authentication request, the sender device may no longer want the secure call.
  • the recipient device may set an authentication support flag in the header field of the SIP INVITE message.
  • the recipient device can compose the SIP INVITE message so that the 'Call-info' field of the SIP INVITE message indicates authentication support.
  • the sender device may receive a SIP response message upon completion of authentication.
  • Authentication complete means that authentication has been completed on the recipient device.
  • authentication is to confirm that the subject providing the call acceptance input in the recipient device is the owner of the recipient device (or a person authorized by the owner).
  • the SIP response message may indicate that the sender device's invite request was successful.
  • the code of the SIP response message may indicate '200 OK'.
  • the sender device can identify that a secure call is possible with the user of the recipient device by receiving a SIP response message indicating the success of the request.
  • the sender device may send a confirmation message to the recipient device for establishment of a secure call.
  • the calling device may establish a session.
  • the sender device can conduct a secure call with the recipient device through a session.
  • the sender device is shown as performing all of the transmission of a SIP INVITE message, reception of a SIP information message, and reception of a SIP response message with one recipient device, but embodiments of the present disclosure are not limited thereto.
  • the other recipient device refers to a device that is different from the recipient device that is the destination of the SIP INVITE message, and refers to the electronic device that is the target of call forwarding.
  • the sender device may establish a session with another recipient device according to operation 607.
  • FIG. 7 illustrates an operation flow of a recipient device for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • a recipient device may receive a SIP INVITE message containing an authentication request.
  • the SIP INVITE message may include an authentication flag.
  • An authentication flag can be set in the header field of the SIP INVITE message.
  • the 'Call-info' field of the SIP INVITE message may indicate an authentication request.
  • the recipient device may identify that the sender device requires authentication of a user of the recipient device.
  • a SIP INVITE message may be transmitted from the sender device through a server.
  • the recipient device may be the electronic device indicated in the SIP INVITE message of the sender device.
  • the recipient device can receive the SIP INVITE message from the sender device through the server.
  • the recipient device may be a target electronic device (e.g., the second recipient device 532 in FIG. 5) following call transfer from the first recipient device (e.g., the first recipient device 531 in FIG. 5).
  • the recipient device which is the target electronic device according to call forwarding, can receive the converted SIP INVITE message from the server.
  • the recipient device in response to receiving a SIP INVITE message, may identify whether it supports authentication according to the sender's request. If the recipient device does not support the authentication function, user input for authentication of the recipient device cannot be received. For example, if user input for authentication of the recipient device cannot be received in the UI for an incoming call, it is difficult for authentication to be completed.
  • the recipient device may identify whether an authentication method is set in response to receiving a SIP INVITE message. If the authentication method in the recipient device is not set (e.g., password not set, lock screen not set), user input for authentication of the recipient device cannot be received.
  • an authentication method e.g., password not set, lock screen not set
  • the recipient device may transmit a SIP information message indicating authentication support.
  • the code of the SIP information message may indicate '181 Ringing'.
  • Authentication according to the caller's request may be performed during the call session establishment procedure. That is, authentication is requested from the recipient before the session is established, and session establishment can be performed only when authentication is successful. Therefore, the recipient device is required to inform the sender whether authentication is supported.
  • the recipient device if the recipient device supports recipient authentication according to the sender's request (e.g., supports an authentication function, an authentication method is set), the recipient device includes information indicating authentication support.
  • a SIP information message can be created.
  • the recipient device can set an authentication support flag in the header field of the SIP INVITE message.
  • the recipient device may compose the SIP INVITE message so that the 'Call-info' field of the SIP INVITE message indicates authentication support.
  • the recipient device may transmit a SIP response message upon completion of authentication.
  • Authentication complete means that authentication has been completed on the recipient device.
  • authentication is to confirm that the subject providing the call acceptance input in the recipient device is the owner of the recipient device (or a person authorized by the owner).
  • the SIP response message may indicate that the invite request in the SIP INVITE message of operation 701 was successful.
  • the code of the SIP response message may indicate '200 OK'.
  • the sender device can identify that a secure call is possible with the user of the recipient device by receiving a SIP response message indicating the success of the request.
  • the recipient device may establish a session.
  • the recipient device may receive a confirmation message from the sender device.
  • the confirmation message is a response to the SIP response message of operation 705.
  • the recipient device can conduct a secure call with the sender device through the session.
  • the recipient device if the recipient device does not support the function of recipient authentication according to the sender's request or the authentication method is not set in the recipient device, the recipient device generates a SIP information message that does not include the authentication status. can do. As depicted in FIG. 4 , whether or not to maintain a secure call may be determined depending on the selection of the user of the calling device.
  • Figure 8 shows an example of a user interface (UI) for a call connection requesting recipient authentication, according to an embodiment of the present disclosure.
  • UI user interface
  • the UI of the sender device 810 may include an object 811 for a secure call.
  • a secure call may refer to a call that requires recipient authentication according to the caller's request according to embodiments. To verify the identity of the recipient, the sender device 810 may require authentication prior to session establishment.
  • the UI for calls may include an object 811 for secure calls.
  • the object 811 for a secure call may be displayed for each recipient object in the recipient list within the contact application, as shown in FIG. 8 .
  • the sender device 810 can make a security call to the recipient device 830. Based on detection of a touch input on object 811, sender device 810 may transmit a SIP INVITE message containing an authentication request to recipient device 830.
  • the input for a security call may be set in a different way from the touch input to the object 811.
  • a touch input is received on the phone icon. It may be displayed through an additional pop-up. Based on detection of additional touch input on the additional pop-up, the sender device 810 can place a secure call to the recipient device 830.
  • the security call may be set in advance in the call menu. The sender device 810 can make a secure call to the recipient device 830 according to predefined user preferences.
  • the UI of the recipient device 830 may include an authentication area 831 for a secure call.
  • the recipient device 830 may display a call UI for the secure call.
  • the recipient device 830 can identify the authentication flag included in the SIP INVITE message.
  • the recipient device 830 may display a call UI for a secure call based on the authentication flag included in the SIP INVITE.
  • the call UI for a secure call may be distinguished from the call UI for a regular phone call.
  • the call UI for a regular phone may include a user experience (UX) screen for entering acceptance or rejection of a connection request.
  • the call UI for a secure call may include a UX screen that requests authentication of the user of the recipient device 830.
  • a portion of the screen of the call UI for a secure call may include an authentication area 831.
  • the authentication area 831 may include a fingerprint-shaped object for receiving a fingerprint input.
  • the recipient device 830 can identify whether the stored fingerprint information matches the received fingerprint input. If the stored fingerprint information matches the received fingerprint input, the recipient device 830 may change the screen of the recipient device 830 to a UX screen for inputting acceptance or rejection of the connection request.
  • the call UI for a secure call may be designed in a different way from the authentication area 831.
  • the authentication method may include entering a password.
  • the call UI for a secure call may include a UX screen for password input.
  • the authentication method may include pattern input.
  • the call UI for a secure call may include a UX screen for pattern input.
  • the authentication method may include iris recognition.
  • the call UI for a secure call may include a UX screen for iris recognition.
  • a UI for inquiring about whether to accept a call is displayed after completion of authentication, but embodiments of the present disclosure are not limited to this.
  • the recipient device 830 may display a UX screen requesting user authentication. That is, secure call connections can only be made through authenticated users.
  • the recipient device 830 may display a UX screen requesting user authentication. That is, responses to security calls can only be performed through authenticated users.
  • the SIP protocol according to embodiments of the present disclosure is defined in RFC 3261.
  • the 'Call-Info' header field can provide additional information about the calling device or the called device depending on whether it is found in the request or response.
  • SIP messages for authentication according to sender requests according to embodiments of the present disclosure may use the 'Call-Info' header field.
  • the 'Call-Info' header field defines two target values (e.g. token) and one general parameter.
  • the first target value is 'jcard', and can be used to connect call data (e.g. rich call data (RCD)) related to the caller's ID'.
  • the second destination value is 'jmin', and can be used to pass defined parameters instead of URI values.
  • the general parameter is 'call-reason' and is used to provide a string or other object. The string or object may be used to convey the intent or reason for the call so that the calling device can better understand the context of the called device's call and the reason for answering the call. That is, the "call-reason" parameter is intended to convey a short text message suitable for display to the end user during a call warning.
  • the message may convey the sender's intention to contact the recipient.
  • the sender device may transmit a message including 'call-reason' to the recipient device.
  • the 'call-reason' parameter is an optional parameter.
  • the SIP INVITE message transmitted from the sender device to the recipient device may be structured as shown in Table 1 below.
  • the SIP INVITE message may include header fields.
  • the parameter 'call-reason' of 'Call-info' in the header field may indicate authentication required.
  • the SIP information message transmitted from the recipient device to the sender device may be structured as shown in Table 2 below.
  • SIP information messages may include header fields.
  • the parameter 'call-reason' of 'Call-info' in the header field may indicate authentication support.
  • FIGS. 9A and 9B a method of requesting authentication from the called party in the IMS call service is proposed through FIGS. 9A and 9B.
  • Figure 9a the operation of the sender device is described
  • Figure 9b the operation of the receiver device is described.
  • FIG. 9A shows the operation flow of a caller device for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • the originating device may transmit an authentication SIP INVITE message.
  • the calling device may send an authentication INVITE message to the network to establish a secure call.
  • the sender device may transmit an authentication SIP INVITE message to the recipient device through a server (e.g., IMS server 521 in FIG. 5, proxy server).
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the authentication request included in the SIP INVITE message is a request for user authentication from the recipient device according to the sender's request.
  • user authentication e.g., fingerprint recognition, pattern recognition, password unlocking
  • the sender device may transmit an authentication SIP INVITE message to request connection to a session for a secure call.
  • the calling device may receive a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the SIP 180 response may indicate whether recipient authentication according to the sender's request is supported, in response to receipt of an authentication SIP INVITE message. Recipient authentication refers to user authentication on the recipient device.
  • the SIP 180 response may include a header field indicating authentication support. The value of the header field of call information may be set to 'authentication support'. Additionally, according to one embodiment, the SIP 180 response may include a header field indicating that authentication is not supported. By not including any information in the value of the header field of the call information, non-authentication may be indicated.
  • the sender device may identify whether the recipient device supports authentication as requested by the sender. If the recipient device supports authentication according to the sender request, the sender device may perform operation 907. If the recipient device does not support authentication according to the sender request, the sender device may perform operation 913. This is because if authentication is not supported, the sender device may no longer want to continue requesting a session connection for a secure call. If it is determined that the recipient device does not support the authentication method, the sender device can maintain or terminate the call depending on the user's selection.
  • the calling device may identify whether a SIP 181 response is received.
  • the SIP 181 response indicates call forwarding on the recipient device. Receiving a SIP 181 response means that the target of the authentication SIP INVITE message is switched.
  • the sender device may receive a SIP 181 response from the server. If a SIP 181 response is received, the sender device may perform operation 915. If a SIP 181 response is not received, the sender device may perform operation 909.
  • the calling device may identify whether a SIP 200 response is received.
  • a SIP 200 response indicates that the session's connection request was successful.
  • the sender device can receive a SIP 200 response from the server. If call forwarding does not occur, the sender device can receive a SIP 200 response from the recipient device through the server. After call forwarding, the sender device may receive a SIP 200 response from the electronic device subject to call forwarding (i.e., a new recipient device) through the server. If a SIP 200 response is received, the sender device may perform operation 911. If a SIP 200 response is not received, the sender device may perform operation 917.
  • the calling device may establish a session connection. Afterwards, the sender device can communicate with the recipient device (or a new recipient device) through the established session connection. For example, a calling device can make a call with a called device using a VoIP service.
  • the calling device may verify security settings.
  • the sender device can check the security settings if the recipient device does not support authentication as requested by the sender or receives a SIP 181 response indicating call forwarding.
  • Security settings may mean user input or predefined user settings of the sender device in response to non-authentication of the recipient device or call forwarding of the recipient device.
  • the sender device may identify from the SIP 180 response of the recipient device that the recipient device does not support authentication as requested by the sender.
  • the sender device may display a user interface (UI) to inquire whether to maintain the call to the user of the sender device.
  • the sender device can receive user input on the UI.
  • the sender device may identify a user setting for no authentication.
  • the sender device may identify from the server's SIP 181 response that the current recipient device is being forwarded to another recipient device (i.e., the electronic device subject to call forwarding).
  • the sender device may display a UI to inquire about whether to maintain a call with another recipient device to the user of the sender device.
  • the sender device can receive user input on the UI.
  • the calling party device may identify user settings for call forwarding.
  • the calling device may determine whether to maintain the call.
  • the calling device may decide whether to maintain the call based on user input or predefined user settings.
  • the call refers to a session for a secure call. If maintaining the call, the calling party device may perform operation 909. If not holding the call, the calling device may perform operation 917.
  • the calling party device may terminate the call.
  • the calling device may terminate the call based on non-receipt of the SIP 200 response.
  • the sender device may receive a force shutdown input from the sender device.
  • the sender device may receive an error response or failure response from the recipient device.
  • the calling party device may perform termination of the call based on deciding not to maintain the call. The calling device may terminate the call because the minimum conditions for recipient authentication as requested by the calling party are not met.
  • FIG. 9B illustrates the operation flow of a recipient device for a call connection requesting recipient authentication in SIP, according to an embodiment of the present disclosure.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the recipient device may receive an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the recipient device may transmit a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the recipient device may determine authentication settings.
  • the recipient device may determine call forwarding settings.
  • the SIP 180 response may indicate whether recipient authentication according to the sender's request is supported, in response to receipt of an authentication SIP INVITE message.
  • Recipient authentication refers to user authentication on the recipient device.
  • a SIP response message may be generated based on whether the recipient device supports an authentication function before establishing a session and whether an authentication method is set in the recipient device. If an authentication method is set in the recipient device and the recipient device supports the recipient authentication function, the recipient device may generate a SIP response message including the authentication status.
  • the authentication status may refer to 'authentication supported'.
  • the recipient device may generate a SIP response message that does not include an authentication status if an authentication method is not set in the recipient device or if the recipient device does not support the recipient authentication function.
  • the sender device may identify that the recipient device does not support authentication based on identifying that the specified header field (e.g., the 'Call-info' field) does not contain any information.
  • the recipient device may identify whether call forwarding is enabled on the recipient device.
  • the recipient device may perform operation 957 when call forwarding is not set on the recipient device.
  • the recipient device may perform operation 967 when call forwarding is set on the recipient device.
  • call forwarding is activated, the recipient device can forward calls by selecting only electronic devices (or terminals) that have an authentication method. If call forwarding is not set up, the recipient device may send a SIP 180 response message containing information indicating authentication support.
  • the recipient device may identify whether to accept the call.
  • the recipient device may identify whether a user input indicating call acceptance or call rejection is received in order to identify whether the call is accepted.
  • the recipient device may perform operation 959 if the call is accepted.
  • the recipient device may perform operation 971 if the call is not accepted.
  • the recipient device may initiate an authentication request procedure.
  • the authentication request procedure refers to recipient authentication according to the sender's request.
  • the recipient device may request authentication from the user of the recipient device.
  • the recipient device may display a user interface requesting specified user input.
  • designated user input may include fingerprint recognition.
  • specified user input may include a password.
  • designated user input may include iris recognition.
  • specified user input may contain a pattern.
  • specified user input may include facial recognition.
  • the recipient device may receive user input received on the user interface.
  • FIG. 9B the recipient device is shown to request authentication from the user only when the user of the recipient device accepts the call; however, embodiments of the present disclosure are not limited to this. Even if the user of the recipient device wishes to reject the call, the recipient device may request authentication from the user.
  • the recipient device may identify whether the authentication request was successful.
  • the recipient device may identify whether the received user input is the designated input to identify whether the authentication request was successful.
  • the recipient device may identify successful authentication if the recognized fingerprint matches stored fingerprint information.
  • the recipient device may identify successful authentication if the recognized face matches stored facial information.
  • the recipient device may identify authentication success if the recognized iris matches stored iris information.
  • the recipient device may identify successful authentication if the entered password matches a stored password.
  • the recipient device can identify successful authentication if the input pattern matches a stored pattern.
  • the recipient device may transmit a SIP 200 response.
  • the SIP 200 response may indicate success in the connection request of the session in the authentication SIP INVITE message of operation 951.
  • the recipient device may send a SIP 200 response based on identifying successful authentication. Transmission of a SIP 200 response may indicate successful authentication at the recipient device. That is, the sender device can identify that the authentication of the user of the recipient device requested by the sender device has been successfully completed through reception of the SIP 200 response.
  • the recipient device may establish a session connection. Thereafter, the recipient device can communicate with the sender device through the established session connection. For example, a called device can make a call with a calling device and a VoIP service.
  • the recipient device can identify the target electronic device.
  • the recipient device can check the electronic device subject to call forwarding. Since the session involves a secure call, recipient authentication is also required on the target electronic device.
  • the recipient device may identify one or more target electronic devices according to call forwarding settings.
  • the recipient device can check the status settings of each of one or more target electronic devices.
  • the status setting indicates whether recipient authentication according to the sender's request is possible in the corresponding electronic device according to embodiments of the present disclosure.
  • the recipient device may identify an electronic device that has an authentication method among one or more target electronic devices.
  • the recipient device may perform authentication setup.
  • the recipient device may perform authentication settings on the electronic device subject to call forwarding. Due to the authentication settings, the target electronic device can perform the recipient authentication procedure according to operations 951 to 965.
  • the called device may terminate the call.
  • the recipient device may perform termination of the call based on authentication failure. Authentication failure may indicate difficulty for the owner of the recipient device to control the recipient device. Because the authentication required by the sender has failed, it is difficult for the recipient device to perform the secure call connection procedure any further.
  • the recipient device may generate a SIP response message indicating a failure or error in the connection request so that the calling device terminates the call. Meanwhile, unlike shown in FIG. 9B, according to another embodiment, the recipient device may wait until the caller device terminates the call.
  • the recipient device may perform call termination based on call rejection. If the user of the recipient device does not accept the call, the recipient device may initiate termination of the call, regardless of whether authentication is successful. The recipient device may generate a SIP response message notifying a failure or error in the connection request. The recipient device may transmit a SIP response message to the sender device.
  • operation 953 may be omitted or operation 953 may be performed after operation 955.
  • call forwarding is activated on the recipient device, the recipient device can forward calls by selecting only terminals with an authentication method. If there is no call forwarding, the recipient device may send a SIP 180 response message containing authentication support status. In response to the user of the called device determining that he or she wishes to accept or reject the call, the called device may request authentication from the user. If it is determined that the recipient device does not support the authentication method, the caller device can maintain or terminate the call depending on the user selection of the caller device.
  • 10A and 10B a processing method that integrates a secure call requiring recipient authentication according to the sender's request and a call forwarding function is described. In Figure 10a, the operation of the sender device is described, and in Figure 10b, the operation of the receiver device is described. Additional logic for call forwarding can be implemented either on the electronic device (sender device or called device) or on the network side.
  • Figure 10a shows the operation flow of a caller device for an authentication procedure when forwarding a call in SIP, according to an embodiment of the present disclosure.
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • the originating device may transmit an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the calling device may receive a SIP 180 response or a SIP 181 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the SIP 181 response indicates call forwarding on the recipient device.
  • the calling party device may identify whether call forwarding is enabled on the called party device.
  • the calling party device may perform operation 1011 when call forwarding is activated on the called party device.
  • the calling party device may perform operation 1007 if the called party device does not have call forwarding enabled.
  • the sender device may identify whether the recipient device supports authentication as requested by the sender.
  • the sender device may perform operation 1009 if the recipient device supports authentication according to the sender request.
  • the sender device may perform operation 1013 if the recipient device does not support authentication according to the sender request.
  • the calling device may perform a secure call procedure.
  • the calling device may perform a secure call procedure, as described through FIGS. 3 to 9B.
  • the secure call procedure refers to a session connection procedure based on authentication of the user of the recipient device.
  • the sender device may check whether the user of the recipient device is authenticated and perform a session connection if the user of the recipient device is authenticated.
  • the calling party device may check the security settings for call forwarding.
  • the calling device may check security settings indicating whether to allow call forwarding for secure calls.
  • the security setting may indicate allowing call forwarding.
  • the sender device may decide whether to perform a session connection or terminate the session based on whether the electronic device subject to call forwarding supports recipient authentication according to the sender's request.
  • the sender device may perform operation 1007 to determine whether to terminate the session connection with the electronic device subject to call forwarding. In FIG. 10A, operation 1007 is shown to be performed after confirming security settings for call forwarding, but embodiments of the present disclosure are not limited to this.
  • the caller device may immediately perform operation 1015 after checking the security settings for call forwarding.
  • the sender device may check the security settings for no authentication.
  • the calling device may determine whether to maintain the call.
  • the calling device may decide whether to maintain the call based on user input or predefined user settings.
  • the call refers to a connection for establishing a secure call session. If maintaining the call, the calling party device may perform operation 1009. If not holding the call, the calling device may perform operation 1017.
  • the caller device may determine whether to maintain or cancel the call in response to the call forwarding notification. For example, the caller device may terminate the call in response to receiving a call forwarding notification, according to predefined settings. As another example, the caller device may display a UI for receiving a user's input in response to receiving a call forwarding notification. Depending on the user input entered into the UI, the caller device may maintain the call or cancel the call.
  • the calling device may terminate the call.
  • the calling device may perform termination of the call based on the calling device deciding not to maintain the call.
  • the calling device may terminate the call because the minimum conditions for recipient authentication as requested by the calling party are not met.
  • Figure 10b shows the operation flow of a recipient device for an authentication procedure when forwarding a call in SIP, according to an embodiment of the present disclosure.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the recipient device may receive an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the recipient device may confirm the call forwarding settings.
  • the recipient device may determine call forwarding settings for secure calls.
  • the call forwarding setting refers to the function of transferring a call received by the recipient device to another device in case the recipient device is absent.
  • the recipient device may identify whether to forward the secure call.
  • the recipient device may perform operation 1061 when the secure call is forwarded.
  • the recipient device may perform operation 1057 if the secure call is not forwarded. That is, the recipient device can identify whether conditional call forwarding is activated.
  • the device may determine call forwarding settings for secure calls.
  • the recipient device may disable call forwarding.
  • the recipient device may disable call forwarding if call forwarding for secure calls is not performed.
  • the recipient device may proceed with the secure call procedure.
  • the recipient device may perform a secure call procedure, as described through FIGS. 3 to 9B.
  • the secure call procedure refers to a session connection procedure based on authentication of the user of the recipient device. Based on the authentication procedure of the recipient device, the recipient device may transmit a SIP response message indicating success of session connection to the sender device.
  • the recipient device can check the status of the target electronic device.
  • the status of the target electronic device may indicate whether the target electronic device supports recipient authentication according to the sender's request according to embodiments of the present disclosure.
  • the status of the target electronic device may indicate whether an authentication method has been set in the target electronic device.
  • the status of the target electronic device may indicate whether the target electronic device supports a recipient authentication function according to the sender's request according to the embodiments of the disclosure.
  • the recipient device can identify whether the target electronic device supports recipient authentication.
  • the recipient device can identify whether the target electronic device supports recipient authentication based on the status of the target electronic device.
  • the recipient device may select an electronic device that supports the authentication method.
  • the recipient device may perform operation 1057 when the target electronic device does not support recipient authentication. This is because there is little need for call forwarding.
  • the recipient device may perform operation 1059 if the target electronic device supports recipient authentication. This is because the recipient device does not need to disable call forwarding because the target electronic device supports authentication.
  • the sender device when transmitting a session connection request, requests user authentication from the recipient device. Meanwhile, information on whether a call forwarding function is set in the recipient device or whether the recipient device supports a user authentication function according to the caller's request may be managed in the server.
  • Embodiments of the present disclosure can also be applied to other deployment types in which the capabilities of each electronic device (or user equipment (UE)) are centrally managed by a server.
  • a call that requires recipient authentication may be referred to as a secure call.
  • the server may manage the security favor service. For example, each electronic device can update information related to the security code to the server. Additionally, for example, each electronic device may retrieve functions related to security calls from the server. below. 11A and 11B, a secure call procedure by server management is described. In Figure 11a, the operation of the sender device is described, and in Figure 11b, the operation of the receiver device is described.
  • Figure 11A shows the operational flow of a sender device for an authentication procedure using capability information in SIP, according to an embodiment of the present disclosure.
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • a calling device may receive capability information from a server.
  • Capability information may include information related to authentication support for the recipient device.
  • the capability information may indicate whether the recipient device supports an authentication function.
  • the authentication function may include displaying a designated UI in response to receipt of the sender's authentication INVITE message. This is because for recipient authentication, for an incoming call, the recipient device is required to display a screen requesting authentication from the user before the call is established.
  • the capability information may include information related to the authentication method set in the recipient device. Capability information may indicate whether an authentication method is set on the recipient device. This is because if the authentication method is not set on the recipient device, recipient authentication itself is difficult to proceed.
  • the sender device may identify whether the recipient device supports authentication.
  • authentication refers to user authentication in the recipient device according to the sender's request.
  • the sender device may perform operation 1105 if the recipient device supports authentication.
  • the sender device may perform operation 1109 if the recipient device does not support authentication.
  • the originating device may transmit an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the calling device may proceed with the secure call procedure.
  • the secure call procedure refers to a session connection procedure based on authentication of the user of the recipient device. Based on the response from the recipient device, it is checked whether the user of the recipient device is authenticated, and if the user of the recipient device is authenticated, a session connection can be performed.
  • the sender device may indicate that authentication is not supported.
  • a user of a calling device may not make a secure call to a called device that does not support authentication.
  • the sender device may indicate that the recipient device that does not support authentication does not support authentication.
  • Figure 11b shows the operational flow of a recipient device for an authentication procedure using capability information in SIP, according to an embodiment of the present disclosure.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the recipient device may receive capability information from the server.
  • Capability information may include information related to the security call of the sender device.
  • the capability information may indicate whether the sender device supports recipient authentication according to the sender request. Since the sender device must include an authentication request in the authentication SIP INVITE message, capability information for the sender device is required.
  • the capability information may include a call forwarding policy of the calling party device. If the policy is set not to maintain a secure call when call forwarding occurs, the recipient device does not need to check the settings for the electronic device subject to call forwarding.
  • the recipient device may receive an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the recipient device may transmit a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the recipient device may generate a SIP 180 response message indicating support for the authentication function to transmit a SIP 180 response.
  • the recipient device may generate a SIP 180 response message based on the capability information received in operation 1151. Based on the capability information of the sender device, the format of the message that must be generated to indicate that the recipient device supports the authentication function may be defined.
  • the recipient device may determine whether to accept the call.
  • the recipient device may perform operation 1159 to determine call acceptance. If the called device rejects the call, it may perform operation 1165.
  • the recipient device may verify user settings.
  • User settings refer to user input for an authentication request.
  • the recipient device can identify the authentication method.
  • the recipient device may perform an authentication request to the user.
  • the recipient device may display a UI requesting authentication to the user.
  • the UI may include an authentication area for fingerprint recognition.
  • the UI may include an authentication area for iris recognition.
  • the UI may include a screen for entering a password.
  • the UI may include a screen for pattern input.
  • the recipient device can confirm user settings according to the authentication request.
  • the recipient device may identify whether authentication was successful.
  • the recipient device may identify whether authentication was successful based on user settings. For example, the recipient device can identify whether fingerprint input according to user settings matches stored fingerprint information to identify whether authentication was successful. As another example, the recipient device may identify whether password input according to user settings matches stored password information in order to identify whether authentication was successful. As another example, the recipient device may identify whether iris input according to user settings matches stored iris information to identify whether authentication was successful. As another example, the recipient device may identify whether a pattern input according to user settings matches stored pattern information in order to identify whether authentication was successful.
  • the recipient device 1230 may identify successful authentication based on whether an authentication timer (eg, the timer in FIG. 13) has expired. Recipient device 1230 may determine that a currently valid authentication result exists if the timer has not expired. The recipient device 1230 can identify successful authentication since a currently valid authentication result exists.
  • the recipient device may proceed with the secure call procedure.
  • the secure call procedure refers to a session connection procedure based on authentication of the user of the recipient device. Based on the authentication procedure of the recipient device, the recipient device may transmit a SIP response message indicating success of session connection to the sender device.
  • the called device may terminate the call.
  • the recipient device may receive a call rejection input. The user of the recipient device may not accept the call. In this case, the recipient device may terminate the call, regardless of whether authentication is successful or not.
  • the recipient device may perform termination of the call based on authentication failure. Authentication failure may indicate difficulty for the owner of the recipient device to control the recipient device. Because the authentication required by the sender has failed, it is difficult for the recipient device to perform the secure call connection procedure any further.
  • the recipient device may generate a SIP response message indicating a failure or error in the connection request so that the calling device terminates the call. Meanwhile, unlike shown in FIG. 11, according to another embodiment, the recipient device may wait until the caller device terminates the call.
  • an authentication SIP INVITE message is described to request a security call.
  • the sender device included information for an authentication request in the SIP INVITE message.
  • the authentication SIP INVITE message may be generated by the server.
  • a method for the server to initiate an authentication procedure is described through FIG. 12.
  • Figure 12 shows an example of signaling for an authentication procedure using a server in SIP, according to an embodiment of the present disclosure.
  • the recipient's electronic device is a mobile termination (MT) and may be referred to as a recipient device.
  • the sender's electronic device is a mobile originator (MO) and may be referred to as a sender device.
  • the recipient device and the sender device illustrate the electronic device 101.
  • a server may be used as a network entity for relaying messages between a sender device and a recipient device.
  • the sender device 1210 can make a call to the recipient device 1230.
  • a recipient authentication request according to embodiments of the present disclosure may be performed by the server 1220.
  • the sender device 1210 may perform registration with the server.
  • the sender device 1210 may register the sender device 1210 with the server.
  • the sender device 1210 may register the service of the sender device 1210 with the server.
  • the sender device 1210 may register the status of the sender device 1210 with the server.
  • the sender device 1210 when requesting a call connection to a specific recipient device (e.g., recipient device 1230), the sender device 1210 may register information indicating that authentication is required with the server.
  • the sender device 1210 may register information indicating that authentication is required to the server when requesting a secure call connection.
  • the sender device 1210 may register information related to the type of secure call with the server so that a determination as to whether it is a secure call can be performed by the server.
  • the sender device 1210 may transmit a SIP INVITE message.
  • the sender device 1210 may transmit a SIP INVITE message to make a call to the recipient device.
  • the SIP INVITE message from the sender device 1210 may not include an authentication request.
  • the sender device 1210 can transmit the SIP INVITE message without inserting separate authentication request information.
  • the server 1220 may perform a service management update.
  • the server 1222 may perform a service management update for the sender device 1210 in response to registration in operation S1201.
  • the server 1220 may confirm the registration service.
  • the server 1220 can confirm the registration service from the SIP INVITE message received from the sender device 1210. Based on the SIP INVITE message, the server 1220 can identify whether the registration service of the sender device 1210 requires recipient authentication. If a call connection to the recipient device 1230, which is a registration service of the sender device 1210, requires recipient authentication, the server 1220 may decide to request recipient authentication. Server 1220 may identify that a secure call is requested from caller device 1210.
  • server 1220 may insert an authentication flag.
  • Server 1220 may rewrite the SIP INVITE message.
  • Server 1220 may insert an authentication flag into the SIP INVITE message received from sender device 1210.
  • the authentication flag may be added to an already existing header (eg, Call-info) or a newly defined header for a secure call.
  • the server 1220 may perform a secure call procedure.
  • the server 1220 may transmit a SIP INVITE message with an authentication flag inserted, that is, an authentication SIP INIVTE message, to the recipient device 1230.
  • Server 1220 may send an authentication SIP INVITE message to request authentication from the user of the recipient device.
  • the recipient device 1230 may perform an authentication request.
  • the recipient device 1230 may request authentication from the user.
  • recipient device 1230 may request authentication from the user to accept the call.
  • the recipient device 1230 may display a UI requesting authentication to the user. Additionally, according to one embodiment, the recipient device 1230 may identify whether a currently valid authentication result exists.
  • recipient device 1230 may identify authentication success.
  • the recipient device may identify authentication success when it receives input specified in the UI.
  • Designated input means input that matches information stored in the recipient device 1230 or a network connected to the recipient device 1230.
  • the recipient device 1230 may identify successful authentication based on whether an authentication timer (eg, the timer in FIG. 13) has expired. Recipient device 1230 may determine that a currently valid authentication result exists if the timer has not expired. The recipient device 1230 can identify successful authentication since a currently valid authentication result exists.
  • an authentication timer eg, the timer in FIG. 13
  • the recipient device 1230 may perform session establishment with the sender device 1210.
  • the recipient device 1230 may transmit a SIP response message (eg, SIP 200 OK) indicating success of the session connection request to the sender device 1210.
  • the sender device 1210 may transmit a confirmation message to the recipient device 1230 in response to receiving the SIP response message.
  • a media session may be established between the sender device 1210 and the recipient device 1230 via the server 1220.
  • Figure 13 shows the operation flow of a recipient device for sender request-based authentication using a timer, according to an embodiment of the present disclosure.
  • a method of operating a timer to optimize the authentication operation in the recipient device is described. If a secure call comes within a specified amount of time (e.g., the length of a timer) since the last successful authentication, the recipient device may skip the authentication request. Timers can be used to reduce overhead due to repeated authentication procedures.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the recipient device may set a timer.
  • a timer may be set based on successful authentication.
  • setting means starting (or triggering) a timer.
  • the recipient device may set a timer based on identifying successful authentication of a user of the recipient device. If one authentication is successful, a timer may start. Additionally, according to one embodiment, the recipient device may set a timer after completion of a security call requiring recipient authentication (that is, after establishment and termination of a session for the security call).
  • the recipient device may receive an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the authentication flag included in the SIP INVITE message may require user authentication from the recipient device.
  • the recipient device may transmit a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the SIP 180 response may indicate whether recipient authentication according to the sender's request is supported, in response to receipt of an authentication SIP INVITE message.
  • the recipient device may determine whether to accept the call.
  • the recipient device may identify whether a user input indicating accept the call or reject the call is received to identify whether to accept the call.
  • the recipient device may perform operation 1309 if the call is accepted.
  • the recipient device may perform operation 1317 if the call is not accepted.
  • the recipient device may identify whether the timer has expired.
  • the recipient device may identify whether the timer has expired in response to the user's decision to accept the incoming call (i.e., entering a call acceptance).
  • the recipient device may skip the authentication request and accept the call if the timer has not expired. If the timer does not expire, the recipient device may store a valid authentication result. The recipient device may use a valid authentication result for the authentication request. Meanwhile, expiration of the timer may mean that valid authentication results are discarded.
  • the recipient device may perform operation S1313. If the timer does not expire, the recipient device may perform operation S1311.
  • the recipient device may perform a secure call procedure.
  • the recipient device may perform a secure call procedure, as described through FIGS. 3 to 9B.
  • the secure call procedure refers to a session connection procedure based on authentication of the user of the recipient device. Based on the authentication procedure of the recipient device, the recipient device may transmit a SIP response message indicating success of session connection to the sender device.
  • the recipient device may perform an authentication request.
  • the recipient device may perform an authentication request to the user.
  • the recipient device may display a UI requesting authentication to the user.
  • the UI may include an authentication area for fingerprint recognition.
  • the UI may include an authentication area for iris recognition.
  • the UI may include a screen for entering a password.
  • the UI may include a screen for pattern input. The recipient device can confirm user settings according to the authentication request.
  • the recipient device may identify whether authentication was successful.
  • the recipient device may identify whether authentication was successful based on user settings. For example, the recipient device can identify whether fingerprint input according to user settings matches stored fingerprint information to identify whether authentication was successful. As another example, the recipient device may identify whether password input according to user settings matches stored password information in order to identify whether authentication was successful. As another example, the recipient device may identify whether iris input according to user settings matches stored iris information to identify whether authentication was successful. As another example, the recipient device may identify whether a pattern input according to user settings matches stored pattern information in order to identify whether authentication was successful.
  • the called device may terminate the call.
  • the recipient device may receive a call reject input at operation 1307. The user of the recipient device may not accept the call. The recipient device may terminate the call, regardless of whether authentication is successful or not.
  • the recipient device may perform termination of the call based on the authentication failure in operation 1305. Authentication failure may indicate difficulty for the owner of the recipient device to control the recipient device. Because the authentication required by the sender has failed, it is difficult for the recipient device to perform the secure call connection procedure any further.
  • a password may be used for the secure call processing method.
  • a password may be additionally used.
  • FIG. 14A illustrates an operational flow of a sender device for sender demand-based authentication using a passcode, according to an embodiment of the present disclosure.
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • the originating device may transmit an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the calling device may receive a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the SIP 180 response may indicate whether recipient authentication according to the sender's request is supported, in response to receipt of an authentication SIP INVITE message.
  • Recipient authentication refers to user authentication on the recipient device.
  • the SIP 180 response may include a header field indicating authentication support.
  • the calling device may receive a SIP 200 response.
  • a SIP 200 response indicates that the session's connection request was successful.
  • the SIP 200 response may include a password.
  • the recipient device may transmit a SIP 200 response including a password to the sender device upon successful authentication according to a pre-designated protocol.
  • the sender device can identify that user authentication of the recipient device was successful.
  • the sender device may additionally perform operation 1407 to determine whether the passwords match.
  • the recipient device may use a password in advance when an authentication method is not set in the recipient device.
  • the recipient device may include the received password input in the SIP 200 response. Once the SIP 200 response is received, the sender device may perform operation 1407 to authenticate the recipient.
  • the sender device may identify whether the password included in the SIP 200 response is the same as the stored password.
  • the sender device may perform operation 1409 if the password included in the SIP 200 response is the same as the stored password.
  • the sender device may perform operation 1411 if the password included in the SIP 200 response is not the same as the stored password.
  • the calling device may perform a secure call procedure. Based on the response from the recipient device, the sender device may check whether the user of the recipient device is authenticated and perform a session connection if the user of the recipient device is authenticated.
  • the calling party device may terminate the call.
  • a password mismatch means that the security conditions are not met.
  • the calling device may decide not to maintain the call.
  • the calling device may perform termination of the call based on the calling device deciding not to maintain the call.
  • the sender device may terminate the call because the password of the recipient device does not match the stored password even if recipient authentication is successful.
  • FIG. 14B shows an operational flow of a recipient device for sender demand-based authentication using a password, according to an embodiment of the present disclosure.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the recipient device may receive an authentication SIP INVITE message.
  • the authentication SIP INVITE message refers to a SIP INVITE message that includes an authentication flag.
  • the header field of SIP INVITE may include information indicating an authentication request (authentication required) (or authentication request).
  • the recipient device may transmit a SIP 180 response.
  • a SIP 180 response indicates that the recipient device is ringing.
  • the recipient device may generate a SIP 180 response message indicating support for the authentication function to transmit a SIP 180 response.
  • the recipient device may generate a SIP 180 response message based on the capability information received in operation 1151. Based on the capability information of the sender device, the format of the message that must be generated to indicate that the recipient device supports the authentication function may be defined.
  • the recipient device may receive a password input in response to the call acceptance.
  • the recipient device can expect to receive a password input for authentication as requested by the caller.
  • the recipient device may display a UI for password entry.
  • the recipient device can receive password input through the UI.
  • the recipient device may use a password input procedure along with an authentication procedure when accepting a call. For two-step authentication, the user authentication request described in FIGS. 3 to 13 and the password input procedure for sender verification may be performed together.
  • the recipient device may send a SIP 200 response containing the password.
  • a password may be used for the secure call processing method.
  • the recipient device may determine authentication settings for receiving a password.
  • the recipient device may transmit the password entered by the user along with the SIP 200 response.
  • a password may be additionally used. To request final confirmation from the sender device, the recipient device may transmit the password entered by the user along with the SIP 200 response.
  • FIG. 15 illustrates the operation flow of a sender device and a receiver device for sender request-based authentication according to screen lock, according to an embodiment of the present disclosure.
  • the SIP message in FIG. 15 may include a short message service (SMS) message for providing text, voice, or video.
  • SMS short message service
  • the calling party device illustrates the calling party device 310 of FIG. 3, the calling party device 410 of FIG. 4, or the calling party device 510 of FIG. 5.
  • the recipient device includes the recipient device 330 in FIG. 3, the recipient device 430 in FIG. 4, and the first recipient device 531, second recipient device 532, and third recipient device 533 in FIG. 5. do.
  • the sender device may generate an authentication header.
  • the authentication header may refer to a header field of a message in which an authentication flag is set.
  • the sender device can set an authentication flag in the header field within the SIP message to request user authentication from the recipient device.
  • the originating device may transmit an authentication SIP message.
  • the sender device may send an authentication SIP message.
  • the authentication SIP message means a SIP message including an authentication flag.
  • the SIP message may include an SMS message.
  • the recipient device may receive an authentication SIP message.
  • the authentication SIP message may include an SMS message requiring recipient authentication.
  • the recipient device may identify whether to display a message on the screen lock.
  • the recipient device may identify whether to display a message on the screen lock, based on the settings of the recipient device. Settings on the recipient device may indicate whether to display the message on the lock screen.
  • the recipient device may perform operation 1509 when displaying a message on the screen lock.
  • the recipient device may perform operation 1513 if the message is not displayed on the screen lock.
  • the recipient device may identify whether the SIP message includes an authentication header.
  • the recipient device may perform operation 1513 if the SIP message does not include an authentication header.
  • the recipient device may perform operation 1511 if the SIP message includes an authentication header.
  • the recipient device may perform an authentication request.
  • the recipient device may request authentication from the user to identify whether to display the SMS message content.
  • the recipient device may display a user interface requesting specified user input.
  • designated user input may include fingerprint recognition.
  • specified user input may include a password.
  • designated user input may include iris recognition.
  • specified user input may contain a pattern.
  • specified user input may include facial recognition.
  • the recipient device may receive user input received on the user interface. In Figure 15, the recipient device is shown to request authentication from the user only when the user of the recipient device accepts the call, but embodiments of the present disclosure are not limited to this. Even if the user of the recipient device wishes to reject the call, the recipient device may request authentication from the user. According to one embodiment, if user authentication is successful, the recipient device may display a message on the lock screen.
  • the recipient device may display a message after unlocking the screen. If the recipient device is unlocked, authentication SIP messages (e.g. authentication SMS) may be treated as regular messages. If the recipient device is set to display message content on the lock screen, and the user requests to display an authentication message, the recipient device may request authentication from the user.
  • authentication SIP messages e.g. authentication SMS
  • a method performed by an electronic device includes transmitting a session initiation protocol (SIP) invitation (INVITE) message for a session connection request to another electronic device through a server.
  • SIP INVITE message may include information indicating an authentication request.
  • the method may include receiving a SIP information message indicating ringing from the other electronic device through the server.
  • the SIP information message to indicate the ringing may include information indicating authentication support.
  • the method may include an operation of identifying whether a SIP response message indicating success of the connection request is received from the other electronic device or the electronic device subject to call forwarding. .
  • the method may include establishing the session in response to receiving the SIP response message. Reception of the SIP response message may indicate successful authentication in the other electronic device or the target electronic device according to the authentication request.
  • the operation of identifying whether the SIP response message is received may include receiving a SIP information message indicating call forwarding for the session from the server.
  • the operation of identifying whether the SIP response message is received includes the operation of identifying whether the SIP response message is received from the target electronic device based on user settings for the call forwarding. can do.
  • the user setting may indicate allowing the session connection request to the electronic device to which the call is being forwarded.
  • the call-information (Call-info) field of the header of the SIP INVITE message may indicate the authentication request.
  • the SIP information message to indicate the ringing may indicate the authentication support.
  • the code number of the SIP information message to indicate the ringing may be 180.
  • the code number of the SIP information message to indicate the call forwarding may be 181.
  • the code number of the SIP response message may be 200.
  • the method may further include receiving a user input to indicate call termination in response to receiving a SIP information message to indicate call forwarding for the session. .
  • the method may further include transmitting a message requesting termination of a connection request for the session to the server in response to the user input.
  • the authentication request may require a designated user input from the other electronic device or the electronic device to which the call is being forwarded.
  • the designated user input may include at least one of a pattern, password, fingerprint recognition result, face recognition result, and iris recognition result.
  • the operation of establishing the session may include the operation of identifying password information included in the SIP response message.
  • the operation of establishing the session may include establishing the session based on a validation result of the password information.
  • a method performed by an electronic device includes receiving a session initiation protocol (SIP) invitation (INVITE) message for a session connection request from another electronic device through a server.
  • SIP session initiation protocol
  • the SIP INVITE message may include an authentication request.
  • the method may include transmitting a SIP information message indicating ringing to the other electronic device through the server.
  • the SIP information message to indicate the ringing may include authentication support.
  • the method may include receiving a designated user input according to the authentication request.
  • the method may include transmitting a SIP response message to indicate success of the connection request to the other electronic device based on the specified user input.
  • the call-information (Call-info) field of the header of the SIP INVITE message may indicate the authentication request.
  • the SIP information message to indicate the ringing may indicate the authentication support.
  • the code number of the SIP information message to indicate the ringing may be 181.
  • the code number of the SIP response message may be 200.
  • the operation of receiving the specified user input may include the operation of displaying a user interface for the specified user input.
  • the designated user input may include at least one of a pattern, password, fingerprint recognition result, face recognition result, and iris recognition result.
  • the SIP response message may include password information corresponding to the authentication request.
  • receiving the user input may include displaying a user interface for the specified user input based on identifying expiration of an authentication timer.
  • the authentication timer may be started when authentication is successful according to another authentication request received before the authentication request.
  • an electronic device includes: memory; at least one transceiver; and at least one processor coupled to the memory and the at least one transceiver.
  • the at least one processor may be configured to transmit a session initiation protocol (SIP) invitation (INVITE) message for a session connection request to another electronic device through a server.
  • the SIP INVITE message may include information indicating an authentication request.
  • the at least one processor may be configured to receive a SIP information message indicating ringing from the other electronic device through the server.
  • the SIP information message to indicate the ringing may include information indicating authentication support.
  • the at least one processor may identify whether a SIP response message indicating success of the connection request is received from the other electronic device or the electronic device subject to call forwarding. .
  • the at least one processor may be configured to establish the session in response to receiving the SIP response message. Reception of the SIP response message may indicate successful authentication in the other electronic device or the target electronic device according to the authentication request.
  • the at least one processor is configured to receive a SIP information message for indicating call forwarding for the session from the server to identify whether the SIP response message is received. It can be.
  • the at least one processor may be configured to identify whether the SIP response message is received from the target electronic device, based on user settings for the call forwarding, to identify whether the SIP response message is received. there is.
  • the user setting may indicate allowing the session connection request to the electronic device to which the call is being forwarded.
  • the call-information (Call-info) field of the header of the SIP INVITE message may indicate the authentication request.
  • the SIP information message to indicate the ringing may indicate the authentication support.
  • the code number of the SIP information message to indicate the ringing may be 180.
  • the code number of the SIP information message to indicate the call forwarding may be 181.
  • the code number of the SIP response message may be 200.
  • the at least one processor may be further configured to receive a user input for indicating call termination, in response to receiving a SIP information message for indicating call forwarding for the session. You can.
  • the at least one processor may be additionally configured to transmit, to the server, a message requesting termination of a connection request for the session in response to the user input.
  • the authentication request may require a designated user input from the other electronic device or the electronic device to which the call is being forwarded.
  • the designated user input may include at least one of a pattern, password, fingerprint recognition result, face recognition result, and iris recognition result.
  • the at least one processor may identify password information included in the SIP response message in order to establish the session.
  • the at least one processor may be configured to establish the session based on a validation result of the password information.
  • an electronic device includes: memory; at least one transceiver; and at least one processor coupled to the memory and the at least one transceiver.
  • the at least one processor may be configured to receive a session initiation protocol (SIP) invitation (INVITE) message for a session connection request from another electronic device through a server.
  • the SIP INVITE message may include an authentication request.
  • the at least one processor may be configured to transmit a SIP information message indicating ringing to the other electronic device through the server.
  • the SIP information message to indicate the ringing may include authentication support.
  • the at least one processor may be configured to receive a designated user input according to the authentication request.
  • the at least one processor may be configured to transmit a SIP response message indicating success of the connection request to the other electronic device based on the specified user input.
  • the call-information (Call-info) field of the header of the SIP INVITE message may indicate the authentication request.
  • the SIP information message to indicate the ringing may indicate the authentication support.
  • the code number of the SIP information message to indicate the ringing may be 181.
  • the code number of the SIP response message may be 200.
  • the at least one processor may be configured to display a user interface for the designated user input in order to receive the designated user input.
  • the designated user input may include at least one of a pattern, password, fingerprint recognition result, face recognition result, and iris recognition result.
  • the SIP response message may include password information corresponding to the authentication request.
  • the at least one processor may be configured to, for receiving the user input, display a user interface for the specified user input based on identifying expiration of an authentication timer. there is.
  • the authentication timer may be started when authentication is successful according to another authentication request received before the authentication request.
  • Electronic devices according to embodiments may include at least one speaker and at least one microphone. Electronic devices according to embodiments may include at least one communication circuit for communicating with a network. Electronic devices according to embodiments may include a processor operably connected to a speaker and a microphone. Electronic devices according to embodiments may include a processor operably connected to the processor.
  • One or more authentication services may be configured on the recipient device. In response to the sender's authentication request, an authentication service may be provided at the recipient device.
  • Embodiments of the present disclosure can provide various solutions through an authentication method before session establishment in the IMS service.
  • the authentication method may be achieved only by changing the electronic device.
  • the authentication method may be used for VoIP services for OTT applications.
  • the authentication method as a network solution, can be used for a new service of an operator.
  • the authentication method may provide integration with call forwarding and voice mail functionality.
  • the authentication method may provide a secure call service in an IoT environment.
  • the authentication method can be linked to the CMC function (Call & Message Continuity).
  • the caller requests recipient authentication when requesting a call (i.e., during a session establishment procedure for a call), thereby protecting the caller's privacy and increasing the reliability of the session to be established.
  • this disclosure provides an apparatus and method for session establishment through authentication in the session initial protocol (SIP).
  • SIP session initial protocol
  • the present disclosure provides an apparatus and method for a call service to request authentication according to the caller's demand.
  • the present disclosure provides an apparatus and method for providing an authentication procedure using an existing editable header field.
  • the apparatus and method according to embodiments of the present disclosure provide security according to the demand of the caller by providing an authentication status to the response message of the callee in the session initial protocol (SIP).
  • SIP session initial protocol
  • a computer-readable storage medium that stores one or more programs (software modules) may be provided.
  • One or more programs stored in a computer-readable storage medium are configured to be executable by one or more processors in an electronic device (configured for execution).
  • One or more programs include instructions that cause the electronic device to execute methods according to embodiments described in the claims or specification of the present disclosure.
  • These programs may include random access memory, non-volatile memory, including flash memory, read only memory (ROM), and electrically erasable programmable ROM. (electrically erasable programmable read only memory, EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other types of disk storage. It can be stored in an optical storage device or magnetic cassette. Alternatively, it may be stored in a memory consisting of a combination of some or all of these. Additionally, multiple configuration memories may be included.
  • non-volatile memory including flash memory, read only memory (ROM), and electrically erasable programmable ROM. (electrically erasable programmable read only memory, EEPROM), magnetic disc storage device, compact disc-ROM (CD-ROM), digital versatile discs (DVDs), or other types of disk storage. It can be stored in an optical storage device or magnetic cassette. Alternatively, it may be stored in a memory consisting of a combination of some or all of these. Additionally, multiple configuration memories may
  • the program may be distributed through a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), or a storage area network (SAN), or a combination thereof. It may be stored on an attachable storage device that is accessible. This storage device can be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communications network may be connected to the device performing embodiments of the present disclosure.
  • a communication network such as the Internet, an intranet, a local area network (LAN), a wide area network (WAN), or a storage area network (SAN), or a combination thereof. It may be stored on an attachable storage device that is accessible. This storage device can be connected to a device performing an embodiment of the present disclosure through an external port. Additionally, a separate storage device on a communications network may be connected to the device performing embodiments of the present disclosure.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Telephonic Communication Services (AREA)

Abstract

실시예들에 따를 때,　전자 장치(electronic device)에 의해 수행되는 방법이 제공된다.　상기 방법은 세션(session)의 연결 요청을 위한 SIP(session initiation protocol)　초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하는 동작을 포함할 수 있다.　상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함할 수 있다.　상기 방법은 인증 지원(authentication support)을 가리키는 정보를 포함하는,　울림(ringing)을 가리키기 위한 SIP　정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하는 동작을 포함할 수 있다.　상기 방법은 상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP　응답(response)　메시지가 수신되는지 여부를 식별하는 동작을 포함할 수 있다.　상기 방법은 상기 SIP　응답 메시지의 수신에 대응하여,　상기 세션을 설립하는 동작을 포함할 수 있다.

Description

세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법
본 개시(disclosure)는 세션 개시 프로토콜(session initiation protocol, SIP)에 관한 것이다. 보다 구체적으로, 본 개시는 SIP에서 인증(authentication)을 위한 장치 및 방법에 관한 것이다.
세션 개시 프로토콜(session initial protocol, SIP)은 멀티미디어 통신에 있어 세션이나 호(call)를 관리하기 위한 시그널링 프로토콜이다. 발신자(caller)와 수신자(callee)는 SIP 프로토콜의 요청과 응답을 통해, 호(call)를 설립할 수 있다. 한편, 발신자는 수신자에게 개인적인(private) 전화를 걸 수 있다. 수신자의 전자 장치에 착신 전환이 설정되어 있거나, 수신자의 전자 장치가 수신자 외 다른 사람의 통제 하에 있다면, 발신자는 전화 연결을 원하지 않을 수 있다.
상기 정보는 본 발명의 이해를 돕기 위한 배경 정보로만 제공된다. 위의 내용 중 어느 것이 개시와 관련하여 선행 기술로 적용될 수 있는지 여부에 대해 어떠한 결정도 이루어지지 않으며 어떠한 주장도 이루어지지 않는다.
실시예들에 따를 때, 전자 장치(electronic device)에 의해 수행되는 방법이 제공된다. 상기 방법은 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하는 동작을 포함할 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함할 수 있다. 상기 방법은 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하는 동작을 포함할 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함할 수 있다. 상기 방법은 상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별하는 동작을 포함할 수 있다. 상기 방법은 상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하는 동작을 포함할 수 있다. 상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리킬 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)에 의해 수행되는 방법이 제공된다. 상기 방법은, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하는 동작을 포함할 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함할 수 있다. 상기 방법은 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하는 동작을 포함할 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함할 수 있다. 상기 방법은 상기 인증 요청에 따른 지정된 사용자 입력을 수신하는 동작을 포함할 수 있다. 상기 방법은 상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하는 동작을 포함할 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)가 제공된다. 상기 전자 장치는, 메모리; 적어도 하나의 송수신기; 및 상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하도록 구성될 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하도록 구성될 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별할 수 있다. 상기 적어도 하나의 프로세서는, 상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하도록 구성될 수 있다. 상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리킬 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)가 제공된다. 상기 전자 장치는, 메모리; 적어도 하나의 송수신기; 및 상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하도록 구성될 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함할 수 있다. 상기 적어도 하나의 프로세서는, 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하도록 구성될 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함할 수 있다. 상기 적어도 하나의 프로세서는, 상기 인증 요청에 따른 지정된 사용자 입력을 수신하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하도록 구성될 수 있다.
본 개시내용의 특정 실시예의 상기 및 다른 측면, 특징 및 이점은 첨부된 도면과 함께 취해진 다음의 설명으로부터 더욱 명백해질 것이다:
도 1은 본 개시의 실시예에 따른, 네트워크 환경 내의 전자 장치의 블록도이다.
도 2는 본 개시의 실시예에 따른 수신자(callee)의 전화 수신(incoming call)의 예를 도시한다.
도 3은 본 개시의 실시예에 따른, 세션 개시 프로토콜(session initiation protocol, SIP)에서 수신자 인증을 요청하는 호(call) 연결을 위한 시그널링의 예를 도시한다.
도 4는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 시그널링의 다른 예를 도시한다.
도 5는 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 서버의 예를 도시한다.
도 6은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 발신자 장치의 동작 흐름을 도시한다.
도 7은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 수신자 장치의 동작 흐름을 도시한다.
도 8은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 유저 인터페이스(user interface, UI)의 예를 도시한다.
도 9a는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 발신자 장치의 동작 흐름을 도시한다.
도 9b는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 수신자 장치의 동작 흐름을 도시한다.
도 10a는 본 개시의 실시예에 따른, SIP에서 착신 전환 시 인증 절차를 위한 발신자 장치의 동작 흐름을 도시한다.
도 10b는 본 개시의 실시예에 따른, SIP에서 착신 전환 시 인증 절차를 위한 수신자 장치의 동작 흐름을 도시한다.
도 11a는 본 개시의 실시예에 따른, SIP에서 능력 정보를 이용하는 인증 절차를 위한 발신자 장치의 동작 흐름을 도시한다.
도 11b는 본 개시의 실시예에 따른, SIP에서 능력 정보를 이용하는 인증 절차를 위한 수신자 장치의 동작 흐름을 도시한다.
도 12는 본 개시의 실시예에 따른, SIP에서 서버를 이용하는 인증 절차를 위한 시그널링의 예를 도시한다.
도 13은 본 개시의 실시예에 따른, 타이머(timer)를 이용하는 발신자 요구 기반 인증을 위한 수신자 장치의 동작 흐름을 도시한다.
도 14a는 본 개시의 실시예에 따른, 암호(passcode)를 이용하는 발신자 요구 기반 인증을 위한 발신자 장치의 동작 흐름을 도시한다.
도 14b는 본 개시의 실시예에 따른, 암호를 이용하는 발신자 요구 기반 인증을 위한 수신자 장치의 동작 흐름을 도시한다.
도 15는 본 개시의 실시예에 따른, 화면 잠금(screen lock)에 따른 발신자 요구 기반 인증을 위한 발신자 장치 및 수신자 장치의 동작 흐름을 도시한다.
도면 전체에 걸쳐 동일한 구성요소를 나타내기 위해 동일한 참조 번호가 사용된다.
첨부된 도면을 참조하는 다음의 설명은 청구의 범위 및 그 등가물에 의해 정의되는 본 발명의 다양한 실시예의 포괄적인 이해를 돕기 위해 제공된다. 이해를 돕기 위해 다양한 특정 세부 사항을 포함하지만 이는 단지 예시로 간주된다. 따라서, 당업자는 본 명세서에 기술된 다양한 실시예의 다양한 변경 및 수정이 본 개시의 범위 및 사상을 벗어나지 않고 이루어질 수 있음을 인식할 것이다. 또한, 공지 기능 및 구성에 대한 설명은 명확성과 간결성을 위하여 생략될 수 있다.
이하의 설명 및 특허청구의 범위에 사용된 용어 및 단어는 서지적 의미로 제한되지 않으며, 발명자가 개시 내용을 명확하고 일관되게 이해하기 위해 사용하는 것일 뿐이다. 따라서, 본 발명의 다양한 실시예에 대한 다음의 설명은 첨부된 청구의 범위 및 그 등가물에 의해 정의된 바와 같이 본 발명을 제한할 목적이 아니라 예시 목적으로만 제공된다는 것이 당업자에게 명백해야 한다.
단수 형태 "a", "an" 및 "the"는 문맥상 명백하게 달리 지시하지 않는 한 복수 지시대상을 포함하는 것으로 이해되어야 한다. 따라서, 예를 들어 "부품 표면"에 대한 언급은 이러한 표면 중 하나 이상에 대한 언급을 포함한다.
본 개시에서 사용되는 용어들은 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 다른 실시예의 범위를 한정하려는 의도가 아닐 수 있다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함할 수 있다. 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 용어들은 본 개시에 기재된 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가질 수 있다. 본 개시에 사용된 용어들 중 일반적인 사전에 정의된 용어들은, 관련 기술의 문맥상 가지는 의미와 동일 또는 유사한 의미로 해석될 수 있으며, 본 개시에서 명백하게 정의되지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다. 경우에 따라서, 본 개시에서 정의된 용어일지라도 본 개시의 실시예들을 배제하도록 해석될 수 없다.
이하에서 설명되는 본 개시의 다양한 실시예들에서는 하드웨어적인 접근 방법을 예시로서 설명한다. 하지만, 본 개시의 다양한 실시예들에서는 하드웨어와 소프트웨어를 모두 사용하는 기술을 포함하고 있으므로, 본 개시의 다양한 실시예들이 소프트웨어 기반의 접근 방법을 제외하는 것은 아니다.
이하 설명에서 사용되는 신호를 지칭하는 용어(예: 신호, 정보, 메시지, 시그널링), 자원을 지칭하는 용어, 연결 상태를 위한 용어(예: 전화(call), 호(call), 세션(session)), 연산 상태를 위한 용어(예: 단계(step), 동작(operation), 절차(procedure)), 데이터를 지칭하는 용어(예: 패킷, 사용자 스트림, 정보(information), 비트(bit), 심볼(symbol), 코드워드(codeword)), 채널을 지칭하는 용어, 네트워크 객체(network entity)들을 지칭하는 용어, 장치의 구성 요소를 지칭하는 용어 등은 설명의 편의를 위해 예시된 것이다. 따라서, 본 개시가 후술되는 용어들에 한정되는 것은 아니며, 동등한 기술적 의미를 가지는 다른 용어가 사용될 수 있다.
또한, 본 개시에서, 특정 조건의 만족(satisfied), 충족(fulfilled) 여부를 판단하기 위해, 초과 또는 미만의 표현이 사용될 수 있으나, 이는 일 예를 표현하기 위한 기재일 뿐 이상 또는 이하의 기재를 배제하는 것이 아니다. '이상'으로 기재된 조건은 '초과', '이하'로 기재된 조건은 '미만', '이상 및 미만'으로 기재된 조건은 '초과 및 이하'로 대체될 수 있다.
또한, 본 개시는, 일부 통신 규격(예: 3GPP(3rd Generation Partnership Project), xRAN(extensible radio access network), O-RAN(open-radio access network)에서 사용되는 용어들을 이용하여 다양한 실시예들을 설명하지만, 이는 설명을 위한 예시일 뿐이다. 본 개시의 다양한 실시예들은, 다른 통신 시스템에서도, 용이하게 변형되어 적용될 수 있다.
도 1은, 본 개시의 실시예에 따른, 네트워크 환경 내의 전자 장치의 블록도이다.
도 1을 참조하면, 네트워크 환경(100)에서 전자 장치(101)는 제1 네트워크(198)(예: 근거리 무선 통신 네트워크)를 통하여 전자 장치(102)와 통신하거나, 또는 제2 네트워크(199)(예: 원거리 무선 통신 네트워크)를 통하여 전자 장치(104) 또는 서버(108) 중 적어도 하나 와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 서버(108)를 통하여 전자 장치(104)와 통신할 수 있다. 일 실시예에 따르면, 전자 장치(101)는 프로세서(120), 메모리(130), 입력 모듈(150), 음향 출력 모듈(155), 디스플레이 모듈(160), 오디오 모듈(170), 센서 모듈(176), 인터페이스(177), 연결 단자(178), 햅틱 모듈(179), 카메라 모듈(180), 전력 관리 모듈(188), 배터리(189), 통신 모듈(190), 가입자 식별 모듈(196), 또는 안테나 모듈(197)을 포함할 수 있다. 어떤 실시예에서는, 전자 장치(101)에는, 이 구성요소들 중 적어도 하나(예: 연결 단자(178))가 생략되거나, 하나 이상의 다른 구성요소가 추가될 수 있다. 어떤 실시예에서는, 이 구성요소들 중 일부들(예: 센서 모듈(176), 카메라 모듈(180), 또는 안테나 모듈(197))은 하나의 구성요소(예: 디스플레이 모듈(160))로 통합될 수 있다.
프로세서(120)는, 예를 들면, 소프트웨어(예: 프로그램(140)을 실행하여 프로세서(120)에 연결된 전자 장치(101)의 적어도 하나의 다른 구성요소(예: 하드웨어 또는 소프트웨어 구성요소)를 제어할 수 있고, 다양한 데이터 처리 또는 연산을 수행할 수 있다. 일 실시예에 따르면, 데이터 처리 또는 연산의 적어도 일부로서, 프로세서(120)는 다른 구성요소(예: 센서 모듈(176) 또는 통신 모듈(190))로부터 수신된 명령 또는 데이터를 휘발성 메모리(132)에 저장하고, 휘발성 메모리(132)에 저장된 명령 또는 데이터를 처리하고, 결과 데이터를 비휘발성 메모리(134)에 저장할 수 있다. 일 실시예에 따르면, 프로세서(120)는 메인 프로세서(121)(예: 중앙 처리 장치 또는 어플리케이션 프로세서) 또는 이와는 독립적으로 또는 함께 운영 가능한 보조 프로세서(123)(예: 그래픽 처리 장치, 신경망 처리 장치(NPU: neural processing unit), 이미지 시그널 프로세서, 센서 허브 프로세서, 또는 커뮤니케이션 프로세서)를 포함할 수 있다. 예를 들어, 전자 장치(101)가 메인 프로세서(121) 및 보조 프로세서(123)를 포함하는 경우, 보조 프로세서(123)는 메인 프로세서(121)보다 저전력을 사용하거나, 지정된 기능에 특화되도록 설정될 수 있다. 보조 프로세서(123)는 메인 프로세서(121)와 별개로, 또는 그 일부로서 구현될 수 있다.
보조 프로세서(123)는, 예를 들면, 메인 프로세서(121)가 인액티브(예: 슬립) 상태에 있는 동안 메인 프로세서(121)를 대신하여, 또는 메인 프로세서(121)가 액티브(예: 어플리케이션 실행) 상태에 있는 동안 메인 프로세서(121)와 함께, 전자 장치(101)의 구성요소들 중 적어도 하나의 구성요소(예: 디스플레이 모듈(160), 센서 모듈(176), 또는 통신 모듈(190))와 관련된 기능 또는 상태들의 적어도 일부를 제어할 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 이미지 시그널 프로세서 또는 커뮤니케이션 프로세서)는 기능적으로 관련 있는 다른 구성요소(예: 카메라 모듈(180) 또는 통신 모듈(190))의 일부로서 구현될 수 있다. 일 실시예에 따르면, 보조 프로세서(123)(예: 신경망 처리 장치)는 인공지능 모델의 처리에 특화된 하드웨어 구조를 포함할 수 있다. 인공지능 모델은 기계 학습을 통해 생성될 수 있다. 이러한 학습은, 예를 들어, 인공지능 모델이 수행되는 전자 장치(101) 자체에서 수행될 수 있고, 별도의 서버(예: 서버(108))를 통해 수행될 수도 있다. 학습 알고리즘은, 예를 들어, 지도형 학습(supervised learning), 비지도형 학습(unsupervised learning), 준지도형 학습(semi-supervised learning) 또는 강화 학습(reinforcement learning)을 포함할 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은, 복수의 인공 신경망 레이어들을 포함할 수 있다. 인공 신경망은 심층 신경망(DNN: deep neural network), CNN(convolutional neural network), RNN(recurrent neural network), RBM(restricted boltzmann machine), DBN(deep belief network), BRDNN(bidirectional recurrent deep neural network), 심층 Q-네트워크(deep Q-networks) 또는 상기 중 둘 이상의 조합 중 하나일 수 있으나, 전술한 예에 한정되지 않는다. 인공지능 모델은 하드웨어 구조 이외에, 추가적으로 또는 대체적으로, 소프트웨어 구조를 포함할 수 있다.
메모리(130)는, 전자 장치(101)의 적어도 하나의 구성요소(예: 프로세서(120) 또는 센서 모듈(176))에 의해 사용되는 다양한 데이터를 저장할 수 있다. 데이터는, 예를 들어, 소프트웨어(예: 프로그램(140) 및, 이와 관련된 명령에 대한 입력 데이터 또는 출력 데이터를 포함할 수 있다. 메모리(130)는, 휘발성 메모리(132) 또는 비휘발성 메모리(134)를 포함할 수 있다.
프로그램(140)은 메모리(130)에 소프트웨어로서 저장될 수 있으며, 예를 들면, 운영 체제(142), 미들 웨어(144) 또는 어플리케이션(146)을 포함할 수 있다.
입력 모듈(150)은, 전자 장치(101)의 구성요소(예: 프로세서(120))에 사용될 명령 또는 데이터를 전자 장치(101)의 외부(예: 사용자)로부터 수신할 수 있다. 입력 모듈(150)은, 예를 들면, 마이크, 마우스, 키보드, 키(예: 버튼), 또는 디지털 펜(예: 스타일러스 펜)을 포함할 수 있다.
음향 출력 모듈(155)은 음향 신호를 전자 장치(101)의 외부로 출력할 수 있다. 음향 출력 모듈(155)은, 예를 들면, 스피커 또는 리시버를 포함할 수 있다. 스피커는 멀티미디어 재생 또는 녹음 재생과 같이 일반적인 용도로 사용될 수 있다. 리시버는 착신 전화를 수신하기 위해 사용될 수 있다. 일 실시예에 따르면, 리시버는 스피커와 별개로, 또는 그 일부로서 구현될 수 있다.
디스플레이 모듈(160)은 전자 장치(101)의 외부(예: 사용자)로 정보를 시각적으로 제공할 수 있다. 디스플레이 모듈(160)은, 예를 들면, 디스플레이, 홀로그램 장치, 또는 프로젝터 및 해당 장치를 제어하기 위한 제어 회로를 포함할 수 있다. 일 실시예에 따르면, 디스플레이 모듈(160)은 터치를 감지하도록 설정된 터치 센서, 또는 상기 터치에 의해 발생되는 힘의 세기를 측정하도록 설정된 압력 센서를 포함할 수 있다.
오디오 모듈(170)은 소리를 전기 신호로 변환시키거나, 반대로 전기 신호를 소리로 변환시킬 수 있다. 일 실시예에 따르면, 오디오 모듈(170)은, 입력 모듈(150)을 통해 소리를 획득하거나, 음향 출력 모듈(155), 또는 전자 장치(101)와 직접 또는 무선으로 연결된 외부 전자 장치(예: 전자 장치(102))(예: 스피커 또는 헤드폰)를 통해 소리를 출력할 수 있다.
센서 모듈(176)은 전자 장치(101)의 작동 상태(예: 전력 또는 온도), 또는 외부의 환경 상태(예: 사용자 상태)를 감지하고, 감지된 상태에 대응하는 전기 신호 또는 데이터 값을 생성할 수 있다. 일 실시예에 따르면, 센서 모듈(176)은, 예를 들면, 제스처 센서, 자이로 센서, 기압 센서, 마그네틱 센서, 가속도 센서, 그립 센서, 근접 센서, 컬러 센서, IR(infrared) 센서, 생체 센서, 온도 센서, 습도 센서, 또는 조도 센서를 포함할 수 있다.
인터페이스(177)는 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 직접 또는 무선으로 연결되기 위해 사용될 수 있는 하나 이상의 지정된 프로토콜들을 지원할 수 있다. 일 실시예에 따르면, 인터페이스(177)는, 예를 들면, HDMI(high definition multimedia interface), USB(universal serial bus) 인터페이스, SD카드 인터페이스, 또는 오디오 인터페이스를 포함할 수 있다.
연결 단자(178)는, 그를 통해서 전자 장치(101)가 외부 전자 장치(예: 전자 장치(102))와 물리적으로 연결될 수 있는 커넥터를 포함할 수 있다. 일 실시예에 따르면, 연결 단자(178)는, 예를 들면, HDMI 커넥터, USB 커넥터, SD 카드 커넥터, 또는 오디오 커넥터(예: 헤드폰 커넥터)를 포함할 수 있다.
햅틱 모듈(179)은 전기적 신호를 사용자가 촉각 또는 운동 감각을 통해서 인지할 수 있는 기계적인 자극(예: 진동 또는 움직임) 또는 전기적인 자극으로 변환할 수 있다. 일 실시예에 따르면, 햅틱 모듈(179)은, 예를 들면, 모터, 압전 소자, 또는 전기 자극 장치를 포함할 수 있다.
카메라 모듈(180)은 정지 영상 및 동영상을 촬영할 수 있다. 일 실시예에 따르면, 카메라 모듈(180)은 하나 이상의 렌즈들, 이미지 센서들, 이미지 시그널 프로세서들, 또는 플래시들을 포함할 수 있다.
전력 관리 모듈(188)은 전자 장치(101)에 공급되는 전력을 관리할 수 있다. 일 실시예에 따르면, 전력 관리 모듈(188)은, 예를 들면, PMIC(power management integrated circuit)의 적어도 일부로서 구현될 수 있다.
배터리(189)는 전자 장치(101)의 적어도 하나의 구성요소에 전력을 공급할 수 있다. 일 실시예에 따르면, 배터리(189)는, 예를 들면, 재충전 불가능한 1차 전지, 재충전 가능한 2차 전지 또는 연료 전지를 포함할 수 있다.
통신 모듈(190)은 전자 장치(101)와 외부 전자 장치(예: 전자 장치(102), 전자 장치(104), 또는 서버(108)) 간의 직접(예: 유선) 통신 채널 또는 무선 통신 채널의 수립, 및 수립된 통신 채널을 통한 통신 수행을 지원할 수 있다. 통신 모듈(190)은 프로세서(120)(예: 어플리케이션 프로세서)와 독립적으로 운영되고, 직접(예: 유선) 통신 또는 무선 통신을 지원하는 하나 이상의 커뮤니케이션 프로세서를 포함할 수 있다. 일 실시예에 따르면, 통신 모듈(190)은 무선 통신 모듈(192)(예: 셀룰러 통신 모듈, 근거리 무선 통신 모듈, 또는 GNSS(global navigation satellite system) 통신 모듈) 또는 유선 통신 모듈(194)(예: LAN(local area network) 통신 모듈, 또는 전력선 통신 모듈)을 포함할 수 있다. 이들 통신 모듈 중 해당하는 통신 모듈은 제1 네트워크(198)(예: 블루투스, WiFi(wireless fidelity) direct 또는 IrDA(infrared data association)와 같은 근거리 통신 네트워크) 또는 제2 네트워크(199)(예: 레거시 셀룰러 네트워크, 5G(5th generation) 네트워크, 차세대 통신 네트워크, 인터넷, 또는 컴퓨터 네트워크(예: LAN 또는 WAN)와 같은 원거리 통신 네트워크)를 통하여 외부의 전자 장치(104)와 통신할 수 있다. 이런 여러 종류의 통신 모듈들은 하나의 구성요소(예: 단일 칩)로 통합되거나, 또는 서로 별도의 복수의 구성요소들(예: 복수 칩들)로 구현될 수 있다. 무선 통신 모듈(192)은 가입자 식별 모듈(196)에 저장된 가입자 정보(예: 국제 모바일 가입자 식별자(IMSI))를 이용하여 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크 내에서 전자 장치(101)를 확인 또는 인증할 수 있다.
무선 통신 모듈(192)은 4G(4th generation) 네트워크 이후의 5G 네트워크 및 차세대 통신 기술, 예를 들어, NR 접속 기술(new radio access technology)을 지원할 수 있다. NR 접속 기술은 고용량 데이터의 고속 송신(eMBB(enhanced mobile broadband)), 단말 전력 최소화와 다수 단말의 접속(mMTC(massive machine type communications)), 또는 고신뢰도와 저지연(URLLC(ultra-reliable and low-latency communications))을 지원할 수 있다. 무선 통신 모듈(192)은, 예를 들어, 높은 데이터 송신률 달성을 위해, 고주파 대역(예: mmWave 대역)을 지원할 수 있다. 무선 통신 모듈(192)은 고주파 대역에서의 성능 확보를 위한 다양한 기술들, 예를 들어, 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO(multiple-input and multiple-output)), 전차원 다중입출력(FD-MIMO: full dimensional MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 또는 대규모 안테나(large scale antenna)와 같은 기술들을 지원할 수 있다. 무선 통신 모듈(192)은 전자 장치(101), 외부 전자 장치(예: 전자 장치(104)) 또는 네트워크 시스템(예: 제2 네트워크(199))에 규정되는 다양한 요구사항을 지원할 수 있다. 일 실시예에 따르면, 무선 통신 모듈(192)은 eMBB 실현을 위한 Peak data rate(예: 20Gbps 이상), mMTC 실현을 위한 손실 Coverage(예: 164dB 이하), 또는 URLLC 실현을 위한 U-plane latency(예: 다운링크(downlink, DL) 및 업링크(uplink, UL) 각각 0.5ms 이하, 또는 라운드 트립 1ms 이하)를 지원할 수 있다.
안테나 모듈(197)은 신호 또는 전력을 외부(예: 외부의 전자 장치)로 송신하거나 외부로부터 수신할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 서브스트레이트(예: PCB) 위에 형성된 도전체 또는 도전성 패턴으로 이루어진 방사체를 포함하는 안테나를 포함할 수 있다. 일 실시예에 따르면, 안테나 모듈(197)은 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다. 이런 경우, 제1 네트워크(198) 또는 제2 네트워크(199)와 같은 통신 네트워크에서 사용되는 통신 방식에 적합한 적어도 하나의 안테나가, 예를 들면, 통신 모듈(190)에 의하여 상기 복수의 안테나들로부터 선택될 수 있다. 신호 또는 전력은 상기 선택된 적어도 하나의 안테나를 통하여 통신 모듈(190)과 외부의 전자 장치 간에 송신되거나 수신될 수 있다. 어떤 실시예에 따르면, 방사체 이외에 다른 부품(예: RFIC(radio frequency integrated circuit))이 추가로 안테나 모듈(197)의 일부로 형성될 수 있다.
다양한 실시예에 따르면, 안테나 모듈(197)은 mmWave 안테나 모듈을 형성할 수 있다. 일 실시예에 따르면, mmWave 안테나 모듈은 인쇄 회로 기판, 상기 인쇄 회로 기판의 제1 면(예: 아래 면)에 또는 그에 인접하여 배치되고 지정된 고주파 대역(예: mmWave 대역)을 지원할 수 있는 RFIC, 및 상기 인쇄 회로 기판의 제2 면(예: 윗 면 또는 측 면)에 또는 그에 인접하여 배치되고 상기 지정된 고주파 대역의 신호를 송신 또는 수신할 수 있는 복수의 안테나들(예: 어레이 안테나)을 포함할 수 있다.
상기 구성요소들 중 적어도 일부는 주변 기기들간 통신 방식(예: 버스, GPIO(general purpose input and output), SPI(serial peripheral interface), 또는 MIPI(mobile industry processor interface))을 통해 서로 연결되고 신호(예: 명령 또는 데이터)를 상호간에 교환할 수 있다.
일 실시예에 따르면, 명령 또는 데이터는 제2 네트워크(199)에 연결된 서버(108)를 통해서 전자 장치(101)와 외부의 전자 장치(104)간에 송신 또는 수신될 수 있다. 외부의 전자 장치(102, 또는 104) 각각은 전자 장치(101)와 동일한 또는 다른 종류의 장치일 수 있다. 일 실시예에 따르면, 전자 장치(101)에서 실행되는 동작들의 전부 또는 일부는 외부의 전자 장치들(102, 104, 또는 108) 중 하나 이상의 외부의 전자 장치들에서 실행될 수 있다. 예를 들면, 전자 장치(101)가 어떤 기능이나 서비스를 자동으로, 또는 사용자 또는 다른 장치로부터의 요청에 반응하여 수행해야 할 경우에, 전자 장치(101)는 기능 또는 서비스를 자체적으로 실행시키는 대신에 또는 추가적으로, 하나 이상의 외부의 전자 장치들에게 그 기능 또는 그 서비스의 적어도 일부를 수행하라고 요청할 수 있다. 상기 요청을 수신한 하나 이상의 외부의 전자 장치들은 요청된 기능 또는 서비스의 적어도 일부, 또는 상기 요청과 관련된 추가 기능 또는 서비스를 실행하고, 그 실행의 결과를 전자 장치(101)로 전달할 수 있다. 전자 장치(101)는 상기 결과를, 그대로 또는 추가적으로 처리하여, 상기 요청에 대한 응답의 적어도 일부로서 제공할 수 있다. 이를 위하여, 예를 들면, 클라우드 컴퓨팅, 분산 컴퓨팅, 모바일 에지 컴퓨팅(MEC: mobile edge computing), 또는 클라이언트-서버 컴퓨팅 기술이 이용될 수 있다. 전자 장치(101)는, 예를 들어, 분산 컴퓨팅 또는 모바일 에지 컴퓨팅을 이용하여 초저지연 서비스를 제공할 수 있다. 다른 실시예에 있어서, 외부의 전자 장치(104)는 IoT(internet of things) 기기를 포함할 수 있다. 서버(108)는 기계 학습 및/또는 신경망을 이용한 지능형 서버일 수 있다. 일 실시예에 따르면, 외부의 전자 장치(104) 또는 서버(108)는 제2 네트워크(199) 내에 포함될 수 있다. 전자 장치(101)는 5G 통신 기술 및 IoT 관련 기술을 기반으로 지능형 서비스(예: 스마트 홈, 스마트 시티, 스마트 카, 또는 헬스 케어)에 적용될 수 있다.
본 개시의 실시예들은 발신자(caller)가 수신자(callee)에게 전화를 거는 상황과 같이 세션 설립(session establishment) 시, 발신자의 요구(demand)에 따라, 수신자의 인증을 수행하기 위한 기술을 제안한다. 발신자 혹은 수신자의 사용자에게 적응적인 인증 방법이 제공됨으로써, 발신자의 프라이버시를 보호하고, 보안 호(security call)에 유용한 전화 서비스가 제공될 수 있다.
도 2는 본 개시의 실시예에 따른 수신자(callee)의 전화 수신(incoming call)의 예를 도시한다. 발신자가 수신자에게 전화를 건 상황이 예로 서술된다. 수신자의 전자 장치는 수신자 장치, 발신자의 전자 장치는 발신자 장치로 지칭될 수 있다. 수신자 장치 및 발신자 장치는 전자 장치(101)를 예시한다.
도 2를 참조하면, 전화가 수신되면, 수신자 장치의 화면은 제1 상태(201)에서 제2 상태(203)으로 전환될 수 있다. 이후, 수신자 장치에서 호 수락 입력이 수신되면, 수신자 장치의 화면은 제2 상태(203)에서 제3 상태(205)로 전환될 수 있다.
수신자 장치는, 전화의 수신(incoming call)이 검출되면, 호 수락을 문의하기 위한 UI(user interface)/UX(user experience)를 사용자에게 제공할 수 있다. 사용자는 별도의 인증 절차 없이, 수락 입력(예: 수락을 지시하는 객체를 클릭(click)하거나 미는(swipe) 입력)을 통해, 전화를 수락할 수 있다. 수신자 장치는, 호 수락 입력의 수신에 대응하여, 세션을 설립할 수 있다. 그러나, 수신자 장치가 전화를 수신하면 수신자 장치의 잠금 여부에 관계없이 통화 활동이 화면에 표시되기 때문에, 수신자 장치의 소유자가 아니더라도 누구나 전화를 잠금 해제하거나 전화를 받을 수 있다. 즉, 수신자 장치에 잠금이 설정되어 있더라도, 상기 잠금의 해제를 위한 인증 단계를 거치지 않고, 세션이 설립될 수 있다.
상술된 문제를 해소하기 위해, 본 개시의 실시예들은 발신자(caller)의 요구(demand)에 따라, 인증 절차를 수행하기 위한 장치 및 방법을 제안한다. 또한, 본 개시의 실시예들은 OTP 관련 통화 또는 민감한 통화가 다른 장치로 착신 전환됨에 따른 문제를 해소하기 위한 장치 및 방법을 제안한다. 또한, 본 개시의 실시예들은 모든 통화에 대하여 인증 절차를 요구하는 대신, 발신자에 의해 설정된 인증 요구 사항에 따라 적응적으로 인증 절차를 요구하기 위한 장치 및 방법을 제안한다.
이하, 본 개시의 실시예들을 설명하기 위해, SIP(session initiation protocol)에서 요구되는 메시지들이 정의된다. SIP는 패킷 교환망에서 회선 교환망 방식의 호 제어가 가능하도록 세션을 제어한다. SIP는 패킷망의 인터넷 상에서 멀티미디어 어플리케이션이 가능하게 한다. SIP는 URL(uniform resource locator) 및 E-mail 형식의 텍스트 기반 어드레싱 방법을 사용한다.
SIP 프로토콜을 이용하는 네트워크 엔티티로서, SIP 클라이언트와 SIP 서버가 정의된다. SIP 클라이언트는 UAC(user agent client)와 UAS(user agent server)를 포함할 수 있다. UAC는 세션 종단에 위치하며, 호를 생성하고 설정을 요청할 수 있다. UAS는 UAC로부터 호를 수락하거나, 거절 또는 리디렉션(redirect)할 수 있다. 일 실시예에 따라, 본 개시의 발신자 장치 및 수신자 장치는 UAS, 서버는 UAS를 의미할 수 있다. SIP 서버는 프록시 서버(proxy server), 등록 서버(register 서버), 리디렉션 서버(redirect server), 위치 서버(location server)를 포함할 수 있다. SIP 서버를 통해, 세션 연결의 확장성이 제공될 수 있다.
SIP 프로토콜을 이용하는 메시지로서, 요청 메시지와 응답 메시지가 정의된다. SIP에서는 호 연결을 위해 요청 및 응답을 포함하는 트랜잭션(transaction)이 요구된다.
SIP 요청은 초대(INVITE), 확인(acknowledgement, ACK), 바이(BYE), 취소(CANCEL), 옵션(OPTIONS), 등록(REGISTER)을 포함할 수 있다. SIP INVITE 메시지는 멀티미디어 세션의 참가를 이용될 수 있다. SIP ACK 메시지는 200 OK 응답을 수신했음을 통지하기 위해 이용될 수 있다. SIP BYE 메시지는 세션의 종료를 위해 이용될 수 있다. SIP CANCEL 메시지는 200 OK 응답을 수신하기 전 기존의 요청을 취소하기 위해 이용될 수 있다. SIP OPTIONS 메시지는 서버에게 능력(capability)을 요청하기 위해 이용될 수 있다. SIP REGISTER는 등록 서버에 사용자 장치(예: user agent(UA))를 등록하기 위해 이용될 수 있다.
SIP 응답은 정보 메시지, 성공 메시지, 리디렉션 메시지, 에러 메시지, 실패 메시지를 포함할 수 있다. 정보 메시지는 '1xx'의 응답 코드에 대응하며, 최종 응답 전에 요청을 처리하는 시간이 200ms이상일 때, 통지될 수 있다. 일 예로, '100'의 응답 코드를 갖는 정보 메시지는 'Trying'을 가리키고, 수신된 요청이 다음 서버로 전송되거나 처리 중임을 나타낸다. 일 예로, '180'의 응답 코드를 갖는 정보 메시지는 'Ringing'을 가리키고, 수신자 장치에 벨이 울리고 있음을 나타낸다. 발신자 장치는 '180'의 응답 코드를 갖는 정보 메시지를 수신하면 링백톤(ring-back tone)을 재생하거나 링백톤의 수신을 준비할 수 있다. 일 예로, '181'의 응답 코드를 갖는 정보 메시지는 'Call is Being Forwarded'을 가리키고, 수신자 장치에서 착신 전환 기능이 설정됨을 나타낸다. 착신 전환의 대상 장치로 호 시도 중임을 통지한다.
성공 메시지는 '2xx'의 응답 코드에 대응하며, 요청이 정상적으로 처리되었음을 나타낸다. 일 예로, '200'의 응답 코드를 갖는 정보 메시지는 'OK'를 가리키고, 요청이 성공적으로 처리되었음을 나타낸다. '202'의 응답 코드를 갖는 정보 메시지는 'Accepted'를 가리키고, 요청의 처리가 승인되었지만 아직 처리 중임을 나타낸다.
리디렉션 메시지는 '3xx'의 응답 코드에 대응하며, 사용자가 새로운 위치로 이동하거나 UA(user agent) 정보가 변경된 서비스로 통합됨을 나타낸다. 에러 메시지는 '4xx'의 응답 코드에 대응하는 발신자 장치의 에러에 따른 메시지와 '5xx'의 응답 코드에 대응하는 서버의 에러에 따른 메시지를 포함할 수 있다. 에러 메시지는 요청이 실패하였음을 나타낸다. 실패 메시지는 '6xx'의 응답 코드에 대응하며, 수신자에 대한 실패 정보(예: 수신자의 상태가 전화를 받지 않음)를 통지한다.
도 3은 본 개시의 실시예에 따른, 세션 개시 프로토콜(session initiation protocol, SIP)에서 발신자(caller)의 요구(demand)에 따른 인증을 위한 시그널링의 예를 도시한다. 수신자의 전자 장치는 MT(mobile termination)으로서, 수신자 장치로 지칭될 수 있다. 발신자의 전자 장치는 MO(mobile originator)로서, 발신자 장치로 지칭될 수 있다. 수신자 장치 및 발신자 장치는 전자 장치(101)를 예시한다.
도 3을 참조하면, 동작(S301)에서, 발신자 장치(310)는 망 장치(320)에게 SIP INVITE 메시지를 전송할 수 있다. 발신자 장치(310)는 망 장치(320)(예: 서버)를 통해 수신자 장치(330)에게 전화를 걸 수 있다. 발신자 장치(310)는 수신자 장치(330)에게 발신자 요구에 따른 인증 요청(authentication request)을 포함하는 전화를 걸 것을 결정할 수 있다. 발신자 장치(310)는 인증 요청을 포함하는 SIP INVITE 메시지를 생성할 수 있다. 발신자 장치(310)는 인증 플래그(authentication flag)를 포함하는 SIP INVITE 메시지를 수신자 장치(330)에게 전송할 수 있다. 예를 들어, 발신자 장치(310)의 사용자는 지정된 입력을 통해, 인증 요청을 포함하는 전화를 걸기 위한 SIP INVITE 메시지를 생성할 수 있다. SIP INVITE 메시지는 인증 요청을 나타낼 수 있다. 일 실시예에 따라, SIP INVITE 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 인증 요청을 가리키기 위한 정보를 포함할 수 있다.
동작(S303)에서, 망 장치(320)는 수신자 장치(330)에게 SIP INVITE 메시지를 전송할 수 있다. SIP INVITE 메시지는 인증 요청을 나타낼 수 있다. 일 실시예에 따라, SIP INVITE 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 인증 요청을 가리키기 위한 정보를 포함할 수 있다.
동작(S305)에서, 수신자 장치(330)는 망 장치(320)에게 SIP 응답 메시지를 전송할 수 있다. 수신자 장치(330)는 SIP INVITE 메시지를 처리할 수 있다. 수신자 장치(330)는 인증 지원을 가리키기 위해, 발신자 장치(310)에게 응답할 수 있다. 수신자 장치(330)는 인증 지원(authentication support)을 가리키는 SIP 응답 메시지를 생성할 수 있다. SIP 응답 메시지는 수신자 장치(330)의 울림(ringing)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 180일 수 있다. 일 실시예에 따라, SIP 응답 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 인증 지원을 가리키기 위한 정보를 포함할 수 있다.
동작(S307)에서, 망 장치(320)는 발신자 장치(310)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 수신자 장치(330)의 울림(ringing)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 180일 수 있다. SIP 응답 메시지는, 발신자 요구에 따른 수신자 인증을 지원함을 가리키는 정보를 포함할 수 있다. 일 실시예에 따라, SIP 응답 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 인증 지원을 가리키기 위한 정보를 포함할 수 있다.
동작(S309)에서, 수신자 장치(330)는 망 장치(320)에게 SIP 응답 메시지를 전송할 수 있다. 일 실시예에 따라, SIP 응답 메시지를 전송하기 위해, 수신자 장치(330)는 인증 방법을 식별할 수 있다. 예를 들어, 인증을 위한 사용자 설정은 패턴(pattern) 입력을 포함할 수 있다. 다른 예를 들어, 인증을 위한 사용자 설정은 비밀번호(password)를 포함할 수 있다. 또 다른 예를 들어, 인증을 위한 사용자 설정은 지문(fingerprint) 인식을 포함할 수 있다. 또 다른 예를 들어, 인증을 위한 사용자 설정은 홍채(iris) 인식을 포함할 수 있다.
일 실시예에 따라, 수신자 장치(330)는 사용자 설정에 기반하여, 인증의 성공 여부를 식별할 수 있다. 예를 들어, 수신자 장치(330)는 수신된 지문 입력이, 수신자 장치(330)에 저장된 지문 정보와 동일하면, 인증의 성공을 식별할 수 있다. 예를 들어, 수신자 장치(330)는 수신된 비밀번호 입력이, 수신자 장치(330)에 저장된 비밀번호 정보와 동일하면, 인증의 성공을 식별할 수 있다. 예를 들어, 수신자 장치(330)는 수신된 홍채 입력이, 수신자 장치(330)에 저장된 홍채 정보와 동일하면, 인증의 성공을 식별할 수 있다. 예를 들어, 수신자 장치(330)는 수신된 패턴 입력이, 수신자 장치(330)에 저장된 패턴 정보와 동일하면, 인증의 성공을 식별할 수 있다. 수신자 장치(330)는 인증의 성공을 식별하는 것에 기반하여, 연결의 성공을 가리키는 SIP 응답 메시지를 생성할 수 있다. 한편, 사용자의 인증이 실패 시, 수신자 장치(330)는 계속 울릴 수 있다. 수신자 장치(330)는 발신자 장치(310)에게 '180 Ringing'에 대응하는 SIP 응답 메시지를 반복적으로 전송할 수 있다. 수신자 장치(330)는 인증 절차의 재시도를 위해, 반복적으로 사용자에게 인증을 요청할 수 있다. 일 실시예에 따라, 재시도의 제한 시간이 설정될 수 있다.
사용자에게 인증을 요청하는 단계는 전화의 수락 혹은 거부를 판단하는 단계와 연속적으로 수행될 수 있다. 일 실시예에 따라, 수신자 장치(330)는, 전화의 수락 입력이 수신되는 경우, 사용자에게 인증을 요청할 수 있다. 수신자 장치(330)는 사용자에게 인증 입력을 요구하는 UI를 표시할 수 있다. 다른 일 실시예에 따라, 전화를 거부하는 입력이 수신되는 경우에도, 사용자에게 인증을 요청할 수 있다. 즉, 수신자 장치(330)는 전화의 수락이나 거부의 입력 모두에 사용자의 인증을 요구할 수 있다. 여기서, 인증은 입력을 제공하는 주체가 수신자 장치(330)의 소유자임을 확인하기 위한 것이다. 또 다른 일 실시예에 따라, 수신자 장치(330)는 전화의 수락 입력 혹은 거절 입력을 요구하기 전에, 사용자에게 인증을 요청할 수 있다. 수신자 장치(330)는, 동작(S303)과 같이, 인증 요청이 포함된 SIP INVITE 메시지를 수신하면, 사용자에게 인증을 요청할 수 있다. 이후, 사용자의 인증이 완료되면, 수신자 장치(330)는 전화의 수락 입력 혹은 거절 입력을 문의하기 위한 UI를 표시할 수 있다.
상술된 절차들을 통해 인증이 성공하면, 수신자 장치(330)는 SIP 응답 메시지를 생성할 수 있다. 다시 말해, SIP 응답 메시지는 발신자 요구에 따른 수신자 인증이 완료된 경우, 수신자 장치(330)로부터 전송될 수 있다. SIP 응답 메시지는 연결 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다.
동작(S311)에서, 망 장치(320)는 발신자 장치(310)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 연결 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다. 발신자 장치(310)는 SIP 응답 메시지에 기반하여, 수신자 장치(330)에서 사용자 인증이 완료되었음을 식별할 수 있다.
동작(S313)에서, 발신자 장치(310)는 수신자 장치(330)와 미디어 세션(media session)을 설립할 수 있다. 이후, 발신자 장치(310)와 수신자 장치(330)는 설립된 미디어 세션을 통해 데이터 패킷을 교환할 수 있다. 예를 들어, 발신자 장치(310)와 수신자 장치(330)는 VoIP(Voice over Internet Protocol) 통화를 수행할 수 있다.
동작(S315)에서, 발신자 장치(310)는 망 장치(320)에게 SIP 요청 메시지를 전송할 수 있다. SIP 요청 메시지는 발신자 장치(310)에서 통화의 종료를 가리킬 수 있다. 동작(S317)에서, 망 장치(320)는 수신자 장치(330)에게 SIP 요청 메시지를 전송할 수 있다. 수신자 장치(330)는 발신자 장치(310)에서 통화의 종료를 요청하였음을 식별할 수 있다.
동작(S319)에서, 수신자 장치(330)는 망 장치(320)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 종료 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다. 동작(S321)에서, 망 장치(320)는 발신자 장치(310)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 종료 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다.
도 3을 참고할 때, 발신자 장치(310)에 의한 통화의 종료가 개시되었으나, 통화의 종료는 수신자 장치(330)에 의해서 개시될 수 있음은 물론이다.
도 4는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 시그널링의 다른 예를 도시한다. 수신자의 전자 장치는 MT(mobile termination)으로서, 수신자 장치로 지칭될 수 있다. 발신자의 전자 장치는 MO(mobile originator)로서, 발신자 장치로 지칭될 수 있다. 수신자 장치 및 발신자 장치는 전자 장치(101)를 예시한다. 도 4에서는 수신자 장치가 발신자 요구에 따른 인증 기능을 지원하지 않거나, 수신자 장치에 보안 설정이 없는 경우, 호의 처리 방법이 서술된다.
도 4를 참조하면, 동작(S401)에서, 발신자 장치(410)는 망 장치(420)에게 SIP INVITE 메시지를 전송할 수 있다. 발신자 장치(410)는 망 장치(420)(예: 서버)를 통해 수신자 장치(430)에게 전화를 걸 수 있다. 발신자 장치(410)는 수신자 장치(430)에게 발신자 요구에 따른 인증 요청(authentication request)을 포함하는 SIP INVITE 메시지를 생성할 수 있다. 동작(S401)은 도 3의 동작(S301)에 대응하는 바, 도 3의 동작(S301)에 서술된 설명이 발신자 장치(410), 망 장치(420), 수신자 장치(430)에게 동일한 방식으로 적용될 수 있다.
동작(S403)에서, 망 장치(420)는 수신자 장치(430)에게 SIP INVITE 메시지를 전송할 수 있다. 동작(S403)은 도 3의 동작(S303)에 대응하는 바, 도 3의 동작(S303)에 서술된 설명이 발신자 장치(410), 망 장치(420), 수신자 장치(430)에게 동일한 방식으로 적용될 수 있다.
동작(S405)에서, 수신자 장치(430)는 망 장치(420)에게 SIP 응답 메시지를 전송할 수 있다. 수신자 장치(430)는 SIP INVITE 메시지를 처리할 수 있다. 수신자 장치(430)는 인증 상태(authentication status)를 포함하지 않는 응답 메시지를 전송할 수 있다. 수신자 장치(430)는, 수신자 장치(430)에서 발신자 요구에 따른 인증 기능을 지원하지 않거나, 보안 설정(예: 화면 잠금의 해제를 위한 설정)이 없는 경우, 인증 상태 없이 SIP 응답 메시지를 생성할 수 있다. 인증 상태가 정의될 수 없기 때문이다. 일 실시예에 따라, SIP 응답 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 어떠한 정보도 포함하지 않도록 설정될 수 있다.
동작(S407)에서, 망 장치(420)는 발신자 장치(410)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 수신자 장치(430)의 울림(ringing)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 180일 수 있다. 일 실시예에 따라, SIP 응답 메시지의 헤더(header)의 호 정보(call information, Call-info) 필드는 어떠한 정보도 포함하지 않도록 설정될 수 있다.
발신자 장치(410)는 인증 상태를 포함하지 않는 응답 메시지를 수신할 수 있다. 수신자 장치(430)가 세션 설립 전 인증 기능을 지원하지 않거나 수신자 장치(430)에서 인증 방법이 설정되지 않은 경우, 발신자 장치(410)는 사용자가 통화 유지 또는 종료와 같은 통화 처리를 수행할 수 있다. 일 실시예에 따라, 발신자 장치(410)는 발신자 장치(410)의 사용자에게 통화의 유지 또는 종료를 문의하기 위한 UI를 표시할 수 있다. 발신자 장치(410)에 수신되는 입력에 따라, 발신자 장치(410)는 '200 OK'를 가리키는 SIP 응답 메시지를 대기하거나, 'BYE'를 가리키는 SIP 요청 메시지를 전송할 수 있다. 다른 일 실시예에 따라, 발신자 장치(410)는 사용자 설정에 따라, 통화를 유지하거나 종료할 수 있다. 예를 들어, 통화가 유지되는 경우, 발신자 장치(410)는 발신자 장치(410)의 화면에 통화가 보안 전화에서 일반 전화로 변경됨을 표시할 수 있다. 다른 예를 들어, 통화가 종료되는 경우, 발신자 장치(410)는 'BYE'를 가리키는 SIP 요청 메시지를 전송할 수 있다. 사용자 설정은 발신자 장치(410)의 설정 메뉴에서 미리 정의되거나, 통화 중 UI에서 입력될 수 있다.
발신자 장치(410)가 수신자 장치(430)에서 사용자 인증이 없더라도, 일반 전화로 호를 유지하길 원하는 경우, 발신자 장치(410)는 '200 OK'를 가리키는 SIP 응답 메시지를 대기할 수 있다. 발신자 장치(410)는 후속 절차(440)를 수행할 수 있다.
동작(S409)에서, 수신자 장치(430)는 망 장치(420)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 연결 요청의 성공(success)을 가리킬 수 있다. 수신자 장치(430)는 인증을 요청하는 단계 없이, 전화의 수락 혹은 거부를 문의하기 위한 UI를 표시할 수 있다. 상기 UI 상에서 전화의 수락 입력을 수신하면, 수신자 장치(430)는 SIP 응답 메시지를 생성할 수 있다. 한편, 도 4에 도시된 바와 달리, 장치(430)는 상기 UI 상에서 전화의 거부 입력을 수신하면, 수신자 장치(430)는 통화의 거부를 알리는 SIP 응답 메시지를 생성할 수 있다.
동작(S411)에서, 망 장치(420)는 발신자 장치(410)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 연결 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다. 발신자 장치(410)는 SIP 응답 메시지에 기반하여, 수신자 장치(430)에서 사용자 인증이 완료되었음을 식별할 수 있다.
동작(S413)에서, 발신자 장치(410)는 수신자 장치(430)와 미디어 세션(media session)을 설립할 수 있다. 이후, 발신자 장치(410)와 수신자 장치(430)는 설립된 미디어 세션을 통해 데이터 패킷을 교환할 수 있다. 예를 들어, 발신자 장치(410)와 수신자 장치(430)는 VoIP(Voice over Internet Protocol) 통화를 수행할 수 있다.
동작(S415)에서, 발신자 장치(410)는 망 장치(420)에게 SIP 요청 메시지를 전송할 수 있다. SIP 요청 메시지는 발신자 장치(410)에서 통화의 종료를 가리킬 수 있다. 동작(S417)에서, 망 장치(420)는 수신자 장치(430)에게 SIP 요청 메시지를 전송할 수 있다. 수신자 장치(430)는 발신자 장치(410)에서 통화의 종료를 요청하였음을 식별할 수 있다.
동작(S419)에서, 수신자 장치(430)는 망 장치(420)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 종료 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다. 동작(S421)에서, 망 장치(420)는 발신자 장치(410)에게 SIP 응답 메시지를 전송할 수 있다. SIP 응답 메시지는 종료 요청의 성공(success)을 가리킬 수 있다. SIP 응답 메시지의 코드 번호는 200일 수 있다.
도 4에서는 발신자 장치(410)에 의한 통화의 종료가 개시되었으나, 통화의 종료는 수신자 장치(430)에 의해서 개시될 수 있음은 물론이다.
도 5는 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 서버의 예를 도시한다. 발신자의 요구에 따른 수신자 인증 절차는 착신 전환(call forwarding)과 함께 결합되어 수행될 수 있다.
도 5를 참조하면, 인증 설정(authentication setting) 상태의 관리는 서버(server)에 의해 수행될 수 있다. 일 실시예에 따라, 서버는 IMS(IP(internet protocol) Multimedia Subsystem) 서버(521)를 포함할 수 있다. 또한, 일 실시예에 따라, 서버는 사업자 또는 OEM의 계정 관리 서버(예: CMC(Computer-mediated Communication) 서버, RCS(Rich Communication Service) 서버)를 포함할 수 있다. 일 실시예에 따라, 착신 전환을 위한 대상 전자 장치의 선택은 수신자 장치에 의해 수행되거나, 망의 네트워크 엔티티에 의해 수행될 수 있다. 착신 전환을 위한 대상 전자 장치의 선택을 위해, 계정 관리 서버(522)가 인증 절차에 개입될(introduced) 수 있다.
발신자 장치(510)가 제1 수신자 장치(531)에게 보안 전화를 건 상황을 가정하자. 보안 전화는 제1 수신자 장치(531)의 인증을 요구할 수 있다. 제1 수신자 장치(531)가 인증을 지원하지 않거나, 인증 설정이 없는 경우, 상기 보안 전화는 다음 수신자 장치인 제2 수신자 장치(532)로 착신 전환될 수 있다. 다음 수신자 장치는 착신 전환을 위해 설정된 대상 전자 장치를 의미한다. 착신 전환은 계정 관리 서버(522)를 통해 수행될 수 있다. 도 3 및 도 4를 통해 서술된 수신자 장치의 동작은, 다음 수신자 장치(예: 제2 수신자 장치(532))에게 동일한 방식으로 적용될 수 있다.
일 실시예에 따라, 제2 수신자 장치(532)는 발신자 요구에 따른 수신자 인증을 수행할 수 있다. 제2 수신자 장치(532)는 IMS 서버(521)를 통해, 발신자 장치(530)에게 SIP 응답 메시지를 전송할 수 있다. 제2 수신자 장치(532)는 제2 수신자 장치(532)의 인증이 완료되었음을 가리키기 위한 SIP 응답 메시지를 전송할 수 있다. 여기서, SIP 응답 메시지는 요청의 성공을 가리키는 '200 OK'를 포함할 수 있다. 한편, 추가적인 일 실시예에 따라, 제1 수신자 장치(531) 대신 제2 수신자 장치(532)가 인증 지원을 가리키는 SIP 응답 메시지를 전송할 수 있다. 인증 지원을 가리키는 SIP 응답 메시지의 코드는 '180 Ringing'을 나타낼 수 있다. 제2 수신자 장치(532)는 인증 지원을 가리키는 SIP 응답 메시지를 요청의 성공을 가리키는 SIP 응답 메시지 전에 전송할 수 있다. 이에 따라, 보안 호가 제2 수신자 장치(532)로 착신 전환이 되더라도, 발신자 장치(510)는 제2 수신자 장치(532)로의 통화 요청을 유지할지, 통화 요청을 종료할지 여부를 결정할 수 있다. 발신자 장치(510)의 사용자가 제2 수신자 장치(532)와의 보안 호를 원치 않을 수 있기 때문이다.
제1 수신자 장치(531)와 마찬가지로, 착신 전환은 제2 수신자 장치(532)에(in) 설정될 수 있다. 제2 수신자 장치(532)의 사용자가 무응답인 경우, 보안 호는 제3 수신자 장치(533)로 착신 전환될 수 있다. 착신 전환 후의 제2 수신자 장치(532)의 동작에 대한 설명은 동일한 방식으로 제3 수신자 장치(533)에게 적용될 수 있다.
상술된 바와 같이, 통화의 알림(notification)은 사용자와 가장 가까운 장치에서 수행되더라도, 통화는 인증된 장치에서만 허용되도록 구성될 수 있다. 이에 따라, 발신자 장치(510)의 프라이버시가 보호되고, 발신자-수신자 간의 보안 통화의 신뢰성이 높아질 수 있다.
도 6은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 발신자 장치의 동작 흐름을 도시한다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다.
도 6을 참조하면, 동작(601)에서, 발신자 장치는 인증 요청을 포함하는 SIP INVITE 메시지를 전송할 수 있다. 발신자 장치는 수신자 장치와 보안 호를 개시할 것을 결정할 수 있다. 일 실시예에 따라, 발신자 장치는 보안 호를 가리키기 위한 사용자의 입력에 기반하여, 상기 수신자 장치와 보안 호를 개시할 것을 결정할 수 있다. 예를 들어, 도 8에 도시된 바와 같이, 보안 호를 가리키는 객체에 터치 입력이 수신됨에 따라, 발신자 장치는 상기 수신자 장치와 보안 호를 개시할 것을 결정할 수 있다. 다른 일 실시예에 따라, 발신자 장치는, 수신자 장치에 대한 미리 정의된 설정에 기반하여, 상기 수신자 장치와의 보안 호를 개시할 것을 결정할 수 있다. 예를 들어, 발신자 장치는, 미리 정의된 그룹 내에 상기 수신자 장치가 포함됨을 식별하는 것에 기반하여, 상기 수신자 장치와 보안 호를 개시할 것을 결정할 수 있다.
발신자 장치는 인증 요청을 포함하는 SIP INVITE 메시지를 생성할 수 있다. 발신자 장치는 SIP INVITE 메시지에 인증 플래그를 설정할 수 있다. 일 실시예에 따라, 발신자 장치는 SIP INVITE 메시지의 헤더 필드에 인증 플래그를 설정할 수 있다. 발신자 장치는 SIP INVITE 메시지의 'Call-info' 필드가 인증 요청(authentication request)를 나타내도록 SIP INVITE 메시지를 작성할 수 있다.
동작(603)에서, 발신자 장치는 인증 지원을 가리키기 위한 SIP 정보 메시지를 수신할 수 있다. SIP 정보 메시지의 코드는 '181 Ringing'을 가리킬 수 있다. 수신자 장치는, 수신자 장치가 발신자 요구에 따른 인증을 사용자에게 요청할 수 있음을 발신자 장치에게 알리기 위해, SIP 정보 메시지를 전송할 수 있다. 수신자 장치가 인증 요구를 사용자에게 제공할 수 없다면, 발신자 장치는 보안 호를 더 이상 원하지 않을 수 있기 때문이다. 일 실시예에 따라, 수신자 장치는 SIP INVITE 메시지의 헤더 필드에 인증 지원 플래그를 설정할 수 있다. 수신자 장치는 SIP INVITE 메시지의 'Call-info' 필드가 인증 지원(authentication support)를 나타내도록 SIP INVITE 메시지를 작성할 수 있다.
동작(605)에서, 발신자 장치는 인증 완료에 따른 SIP 응답 메시지를 수신할 수 있다. 인증 완료는 수신자 장치에서 인증이 완료되었음을 의미한다. 여기서, 인증은 수신자 장치에서 호 수락의 입력을 제공하는 주체가 수신자 장치의 소유자(또는 소유자로부터 허가된 자)임을 확인하기 위한 것이다. SIP 응답 메시지는 발신자 장치의 초대(invite) 요청이 성공임을 가리킬 수 있다. SIP 응답 메시지의 코드는 '200 OK'를 가리킬 수 있다. 발신자 장치는 요청의 성공을 가리키는 SIP 응답 메시지를 수신함으로써, 수신자 장치의 사용자와 보안 통화가 가능함을 식별할 수 있다. 발신자 장치는 보안 통화의 설립을 위해, 확인 메시지를 수신자 장치에게 전송할 수 있다.
동작(607)에서, 발신자 장치는 세션을 설립할 수 있다. 발신자 장치는 세션을 통해, 수신자 장치와 보안 통화를 수행할 수 있다.
도 6에서는 발신자 장치가 하나의 수신자 장치와 SIP INVITE 메시지의 전송, SIP 정보 메시지의 수신, 및 SIP 응답 메시지의 수신 모두를 수행하는 것으로 도시되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 일 실시예에 따라, 수신자 장치에 착신 전환이 설정된 경우, 동작(603)에 따른 SIP 정보 메시지 및 동작(605)에 따른 SIP 응답 메시지 중 적어도 하나는, 다른 수신자 장치로부터 수신될 수 있다. 여기서 다른 수신자 장치란, SIP INVITE 메시지의 목적지인 수신자 장치와 다른 장치로서, 착신 전환의 대상 전자 장치를 의미한다. 또한, 발신자 장치는 다른 수신자 장치와 동작(607)에 따른 세션을 설립할 수 있다.
도 7은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 수신자 장치의 동작 흐름을 도시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 7을 참조하면, 동작(701)에서, 수신자 장치는 인증 요청을 포함하는 SIP INVITE 메시지를 수신할 수 있다. SIP INVITE 메시지는 인증 플래그를 포함할 수 있다. SIP INVITE 메시지의 헤더 필드에 인증 플래그가 설정될 수 있다. SIP INVITE 메시지의 'Call-info' 필드는 인증 요청(authentication request)을 나타낼 수 있다. 수신자 장치는, 발신자 장치가 수신자 장치의 사용자의 인증을 요구함을 식별할 수 있다.
일 실시예에 따라, SIP INVITE 메시지는 서버를 통해 발신자 장치로부터 전송될 수 있다. 예를 들어, 수신자 장치가 발신자 장치의 SIP INVITE 메시지에 지시된 전자 장치일 수 있다. 수신자 장치는 서버를 통해 발신자 장치로부터 SIP INVITE 메시지를 수신할 수 있다. 다른 예를 들어, 수신자 장치는 첫 수신자 장치(예: 도 5의 제1 수신자 장치(531))의 착신 전환에 따른 대상 전자 장치(예: 도 5의 제2 수신자 장치(532))일 수 있다. 착신 전환에 따른 대상 전자 장치인 수신자 장치는 서버로부터 전환된 SIP INVITE 메시지를 수신할 수 있다.
일 실시예에 따라, 수신자 장치는 SIP INVITE 메시지의 수신에 대응하여, 발신자 요구에 따른 인증을 지원하는지 여부를 식별할 수 있다. 수신자 장치가 인증 기능을 지원하지 않는다면, 수신자 장치의 인증을 위한 사용자 입력을 수신할 수 없기 때문이다. 예를 들어, 전화 수신(incoming call)에 대한 UI에서 수신자 장치의 인증을 위한 사용자 입력을 수신할 수 없다면, 인증이 완료되기 어렵다.
일 실시예에 따라, 수신자 장치는 SIP INVITE 메시지의 수신에 대응하여, 인증 방법이 설정되어 있는지 식별할 수 있다. 수신자 장치 내 인증 방법이 설정되어 있지 않다면(예: 암호 미설정, 잠금 화면 미설정), 수신자 장치의 인증을 위한 사용자 입력을 수신할 수 없기 때문이다.
동작(703)에서, 수신자 장치는 인증 지원을 가리키는 SIP 정보 메시지를 전송할 수 있다. SIP 정보 메시지의 코드는 '181 Ringing'을 가리킬 수 있다. 발신자 요구에 따른 인증은, 호의 세션 설립 절차 도중에 수행될 수 있다. 즉, 세션이 설립되기 전에 인증을 수신자에게 요구하고, 인증 성공시에만 세션 설립이 수행될 수 있다. 따라서, 수신자 장치는 인증의 지원 여부를 발신자에게 알릴 것이 요구된다. 일 실시예에 따라, 수신자 장치는, 수신자 장치에서 발신자 요구에 따른 수신자 인증을 지원하는 경우(예: 인증 기능을 지원, 인증 방법이 설정됨), 인증 지원(authentication support)을 가리키는 정보를 포함하는 SIP 정보 메시지를 생성할 수 있다. 수신자 장치는 SIP INVITE 메시지의 헤더 필드에 인증 지원 플래그를 설정할 수 있다. 수신자 장치는 SIP INVITE 메시지의 'Call-info' 필드가 인증 지원를 나타내도록 SIP INVITE 메시지를 작성할 수 있다.
동작(705)에서, 수신자 장치는 인증 완료에 따른 SIP 응답 메시지를 전송할 수 있다. 인증 완료는 수신자 장치에서 인증이 완료되었음을 의미한다. 여기서, 인증은 수신자 장치에서 호 수락의 입력을 제공하는 주체가 수신자 장치의 소유자(또는 소유자로부터 허가된 자)임을 확인하기 위한 것이다. SIP 응답 메시지는 동작(701)의 SIP INVITE 메시지의 초대(invite) 요청이 성공임을 가리킬 수 있다. SIP 응답 메시지의 코드는 '200 OK'를 가리킬 수 있다. 발신자 장치는 요청의 성공을 가리키는 SIP 응답 메시지를 수신함으로써, 수신자 장치의 사용자와 보안 통화가 가능함을 식별할 수 있다.
동작(707)에서, 수신자 장치는 세션을 설립할 수 있다. 수신자 장치는 발신자 장치로부터 확인 메시지를 수신할 수 있다. 확인 메시지는 동작(705)의 SIP 응답 메시지에 대한 응답이다. 수신자 장치는 세션을 통해, 발신자 장치와 보안 통화를 수행할 수 있다.
도 7에 도시된 바와 달리, 수신자 장치에서 발신자 요구에 따른 수신자 인증의 기능을 지원하지 않거나, 인증 방법이 수신자 장치에 설정되지 않은 경우, 수신자 장치는, 인증 상태를 포함하지 않는 SIP 정보 메시지를 생성할 수 있다. 도 4에 서술된 바와 같이, 발신자 장치의 사용자의 선택에 따라 보안 호의 유지 여부가 결정될 수 있다.
도 8은 본 개시의 실시예에 따른, 수신자 인증을 요청하는 호 연결을 위한 유저 인터페이스(user interface, UI)의 예를 도시한다.
도 8을 참조하면, 발신자 장치(810)의 UI는 보안 호를 위한 객체(811)를 포함할 수 있다. 보안 호는, 실시예들에 따른 발신자 요구에 따른 수신자 인증이 전제되는 전화를 의미할 수 있다. 수신자의 신원을 확인하기 위해, 발신자 장치(810)는 세션 설립 전에 인증을 요구할 수 있다. 보안 호와 일반 전화를 구별하기 위하여, 통화를 위한 UI는 보안 호를 위한 객체(811)를 포함할 수 있다. 예를 들어, 보안 호를 위한 객체(811)는 도 8에 도시된 바와 같이, 연락처 어플리케이션 내의 수신자 목록의 수신자 객체 별로 표시될 수 있다. 객체(811)에 터치 입력이 수신되는 경우, 발신자 장치(810)는 수신자 장치(830)에게 보안 호를 걸 수 있다. 객체(811) 상에서의 터치 입력의 검출에 기반하여, 발신자 장치(810)는 수신자 장치(830)에게 인증 요청을 포함하는 SIP INVITE 메시지를 전송할 수 있다.
한편, 도 8에 도시된 바와 달리, 보안 호를 위한 입력은 객체(811)로의 터치 입력과 다른 방식으로 설정될 수 있다. 일 실시예에 따라, 전화 아이콘에 터치 입력이 수신되면. 추가적인 팝업(pop-up)을 통해 표시될 수 있다. 추가적인 팝업 상에서의 추가적인 터치 입력의 검출에 기반하여, 발신자 장치(810)는 수신자 장치(830)에게 보안 호를 걸 수 있다. 다른 일 실시예에 따라, 보안 호는 통화 메뉴(menu)에서 미리 설정될 수 있다. 발신자 장치(810)는 미리 정의된 사용자 기본 설정(user preferences)에 따라 수신자 장치(830)에게 보안 호를 걸 수 있다.
수신자 장치(830)의 UI는 보안 호를 위한 인증 영역(831)을 포함할 수 있다. 발신자 장치(810)가 수신자 장치(830)에게 보안 호를 걸면, 수신자 장치(830)는 보안 호를 위한 통화 UI를 표시할 수 있다. 수신자 장치(830)는 SIP INVITE 메시지에 포함된 인증 플래그를 식별할 수 있다. 수신자 장치(830)는 SIP INVITE에 포함된 인증 플래그에 기반하여, 보안 호를 위한 통화 UI를 표시할 수 있다.
일 실시예에 따라, 보안 호를 위한 통화 UI는 일반 전화를 위한 통화 UI와 구별될 수 있다. 일반 전화를 위한 통화 UI는 연결 요청의 수락 또는 거부를 입력하기 위한 UX(user experience) 화면을 포함할 수 있다. 보안 호를 위한 통화 UI는 수신자 장치(830)의 사용자의 인증을 요구하는 UX 화면을 포함할 수 있다. 보안 호를 위한 통화 UI의 화면 일부는 인증 영역(831)을 포함할 수 있다. 상기 인증 영역(831)은 지문 입력을 수신하기 위한, 지문 모양의 객체를 포함할 수 있다. 수신자 장치(830)의 인증 영역(831)에 지문 입력이 수신되면, 수신자 장치(830)는 저장된 지문 정보와 수신된 지문 입력이 일치하는지 여부를 식별할 수 있다. 저장된 지문 정보와 수신된 지문 입력이 일치하는 경우, 수신자 장치(830)는 수신자 장치(830)의 화면을 연결 요청의 수락 또는 거부를 입력하기 위한 UX 화면으로 변경할 수 있다.
도 8에 도시된 바와 달리, 보안 호를 위한 통화 UI는 인증 영역(831)과는 다른 방식으로 디자인될 수 있다. 일 실시예에 따라, 인증 방법은 비밀번호의 입력을 포함할 수 있다. 보안 호를 위한 통화 UI는 비밀번호 입력을 위한 UX 화면을 포함할 수 있다. 다른 일 실시예에 따라, 인증 방법은 패턴 입력을 포함할 수 있다. 보안 호를 위한 통화 UI는 패턴 입력을 위한 UX 화면을 포함할 수 있다. 또 다른 일 실시예에 따라, 인증 방법은 홍채 인식을 포함할 수 있다. 보안 호를 위한 통화 UI는 홍채 인식을 위한 UX 화면을 포함할 수 있다.
도 8에서는 인증 완료 후, 호 수락 여부를 문의하기 위한 UI가 표시되는 것으로 서술되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 일 실시예에 따라, 일반 전화를 위한 UI에서 호 수락의 입력이 수신되면, 수신자 장치(830)는 사용자 인증을 요구하는 UX 화면을 표시할 수 있다. 즉, 보안 호의 연결은 인증된 사용자를 통해서만 수행될 수 있다. 일 실시예에 따라, 일반 전화를 위한 UI에서 호 수락의 입력 혹은 호 거절의 입력이 수신된 후, 수신자 장치(830)는 사용자 인증을 요구하는 UX 화면을 표시할 수 있다. 즉, 보안 호에 대한 응답은 인증된 사용자를 통해서만 수행될 수 있다.
본 개시의 실시예들에 따른 SIP 프로토콜은 RFC 3261에서 정의된다. RFC 3261를 참조하면, 'Call-Info' 헤더 필드는 요청 또는 응답에서 발견되는지 여부에 따라 발신자 장치 또는 수신자 장치에 대한 추가 정보를 제공할 수 있다. 본 개시의 실시예들에 따른 발신자 요구에 따른 인증을 위한 SIP 메시지들은'Call-Info' 헤더 필드를 이용할 수 있다.
'Call-Info' 헤더 필드는 두 개의 목적 값들(예: 토큰)과 하나의 일반 매개변수(parameter)를 정의한다. 첫 번째 목적 값은 'jcard'이며, 발신자의 ID'와 관련된 통화 데이터(예: RCD(rich call data))를 연결하기 위해 이용될 수 있다. 두번째 목적 값은 'jmin'이며, URI 값을 대신 정의된 매개변수를 전달하기 위해 이용될 수 있다. 일반 매개변수는 'call-reason'이고, 문자열(string) 또는 기타 객체(object)를 제공하는 데 이용된다. 문자열 또는 객체는, 발신자 장치가 수신자 장치의 통화의 컨텍스트(context)와 전화에 응답하라는 이유를 더 잘 이해할 수 있도록, 전화를 건 의도 또는 이유를 전달하는데 사용될 수 있다. 즉, "call-reason" 매개변수는 호출 경고 중에 최종 사용자에게 표시하기에 적합한 짧은 텍스트 메시지를 전달하기 위한 것이다. RFC 2119을 참고할 때, 'call-reason'을 포함하는 메시지는 160자를 넘지 않아야 한다(SHOULD). 'call-reason'을 지원하는 발신자 장치 또는 수신자 장치의 디스플레이는 화면에 맞지 않는 메시지를 강제로 잘라낼 수 있다. 상기 메시지는 수신자에게 연락하려는 발신자의 의도를 전달할 수 있다. 일 실시예에 따라, 발신자 장치는 'call-reason'을 포함하는 메시지를 수신자 장치에게 전송할 수 있다. 'call-reason' 매개변수는 선택적 매개변수이다.
일 실시예에 따라, 발신자 장치가 수신자 장치에게 전송하는 SIP INVITE 메시지는 하기의 표 1과 같이 구성될 수 있다. SIP INVITE 메시지는 헤더 필드를 포함할 수 있다. 헤더 필드의 'Call-info'의 매개변수 'call-reason'은 인증 요구(authentication required)를 가리킬 수 있다.
Authentication SIP INVITE
INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
Call-info: call-reason="authentication required"
일 실시예에 따라, 수신자 장치가 발신자 장치에게 전송하는 SIP 정보 메시지는 하기의 표 2와 같이 구성될 수 있다. SIP 정보 메시지는 헤더 필드를 포함할 수 있다. 헤더 필드의 'Call-info'의 매개변수 'call-reason'은 인증 지원(authentication support)를 가리킬 수 있다.
Authentication SIP 180 RINGING
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101
From: Alice ;tag=9fxced76sl
To: Bob ;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact:
Content-Length: 0
Call-info: call-reason="authentication support"
이하, 도 9a 및 도 9b를 통해 IMS 호 서비스에서 착신 측에 인증을 요청하는 방법을 제안한다. 도 9a에서는 발신자 장치의 동작이, 도 9b에서는 수신자 장치의 동작이 서술된다.
도 9a는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 발신자 장치의 동작 흐름을 도시한다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다.
도 9a를 참조하면, 동작(901)에서, 발신자 장치는 인증 SIP INVITE 메시지를 전송할 수 있다. 발신자 장치는 보안 호를 설정하기 위해 네트워크에 인증 INVITE 메시지를 전송할 수 있다. 발신자 장치는 서버(예: 도 5의 IMS 서버(521), 프록시 서버)를 통해 수신자 장치에게 인증 SIP INVITE 메시지를 전송할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다. SIP INVITE 메시지에 포함되는 인증 요청은, 발신자의 요청에 따라, 수신자 장치에서 사용자 인증을 요청하는 것이다. 수신자 장치의 사용자의 신원을 확인하기 위해, 사용자 인증(예: 지문 인식, 패턴 인식, 비밀번호 해제)이 요구될 수 있다. 발신자 장치는 보안 호를 위한 세션의 연결 요청을 위해, 인증 SIP INVITE 메시지를 전송할 수 있다.
동작(903)에서, 발신자 장치는 SIP 180 응답을 수신할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 일 실시예에 따라, SIP 180 응답은, 인증 SIP INVITE 메시지의 수신에 대응하여, 발신자 요구에 따른 수신자 인증의 지원 여부를 가리킬 수 있다. 수신자 인증이란, 수신자 장치에서 사용자 인증을 의미한다. 일 실시예에 따라, SIP 180 응답은 인증 지원을 가리키는 헤더 필드를 포함할 수 있다. 호 정보의 헤더 필드의 값이 '인증 지원'으로 설정될 수 있다. 또한, 일 실시예에 따라, SIP 180 응답은 인증 미지원을 가리키는 헤더 필드를 포함할 수 있다. 호 정보의 헤더 필드의 값에 어떠한 정보도 포함되지 않음으로써, 인증 미지원이 지시될 수 있다.
동작(905)에서, 발신자 장치는 수신자 장치가 발신자 요구에 따른 인증을 지원하는지 여부를 식별할 수 있다. 수신자 장치가 발신자 요구에 따른 인증을 지원하는 경우, 발신자 장치는 동작(907)을 수행할 수 있다. 수신자 장치가 발신자 요구에 따른 인증을 지원하지 않는 경우, 발신자 장치는 동작(913)을 수행할 수 있다. 인증을 지원하지 않는다면, 발신자 장치는 보안 호를 위한 세션의 연결 요청을 더 이상 지속하길 원하지 않을 수 있기 때문이다. 수신자 장치가 인증 방식을 지원하지 않는 것으로 판단되면, 발신자 장치는 사용자 선택에 따라 통화를 유지하거나 종료할 수 있다.
동작(907)에서, 발신자 장치는 SIP 181 응답이 수신되는지 여부를 식별할 수 있다. SIP 181 응답은 수신자 장치의 착신 전환을 가리킨다. SIP 181 응답의 수신은 인증 SIP INVITE 메시지의 대상(target)이 전환됨을 의미한다. 발신자 장치는 SIP 181 응답을 서버로부터 수신할 수 있다. SIP 181 응답이 수신되는 경우, 발신자 장치는 동작(915)을 수행할 수 있다. SIP 181 응답이 수신되지 않는 경우, 발신자 장치는 동작(909)을 수행할 수 있다.
동작(909)에서, 발신자 장치는 SIP 200 응답이 수신되는지 여부를 식별할 수 있다. SIP 200 응답은 세션의 연결 요청이 성공임을 가리킨다. 발신자 장치는 SIP 200 응답을 서버로부터 수신할 수 있다. 착신 전환이 발생하지 않은 경우, 발신자 장치는 수신자 장치로부터 서버를 통해 SIP 200 응답을 수신할 수 있다. 착신 전환 이후, 발신자 장치는 착신 전환의 대상 전자 장치(즉, 새로운 수신자 장치)로부터 서버를 통해 SIP 200 응답을 수신할 수 있다. SIP 200 응답이 수신되는 경우, 발신자 장치는 동작(911)을 수행할 수 있다. SIP 200 응답이 수신되지 않는 경우, 발신자 장치는 동작(917)을 수행할 수 있다.
동작(911)에서, 발신자 장치는 세션 연결을 설립할 수 있다. 이후, 발신자 장치는 설립된 세션 연결을 통해 수신자 장치(혹은 새로운 수신자 장치)와 통신을 수행할 수 있다. 예를 들어, 발신자 장치는 수신자 장치와 VoIP 서비스에 따른 전화를 수행할 수 있다.
동작(913)에서, 발신자 장치는 보안 설정을 확인할 수 있다. 발신자 장치는, 수신자 장치가 발신자 요구에 따른 인증을 지원하지 않거나, 착신 전환을 가리키는 SIP 181 응답을 수신하는 경우, 보안 설정을 확인할 수 있다. 보안 설정이란, 수신자 장치의 인증 미지원 혹은 수신자 장치의 착신 전환에 대응하여, 발신자 장치의 사용자 입력 또는 미리 정의된 사용자 설정을 의미할 수 있다.
일 실시예에 따라, 발신자 장치는, 수신자 장치의 SIP 180 응답으로부터, 수신자 장치가 발신자 요구에 따른 인증을 지원하지 않음을 식별할 수 있다. 발신자 장치는, 발신자 장치의 사용자에게 호의 유지 여부를 문의하기 위한 사용자 인터페이스(user interface, UI)를 표시할 수 있다. 발신자 장치는, 상기 UI 상에서 사용자 입력을 수신할 수 있다. 다른 일 실시예에 따라, 발신자 장치는 인증 미지원에 대한 사용자 설정을 식별할 수 있다.
일 실시예에 따라, 발신자 장치는, 서버의 SIP 181 응답으로부터, 현재 수신자 장치가 다른 수신자 장치(즉, 착신 전환의 대상 전자 장치)로 착신 전환됨을 식별할 수 있다. 발신자 장치는, 발신자 장치의 사용자에게 다른 수신자 장치와의 호의 유지 여부를 문의하기 위한 UI를 표시할 수 있다. 발신자 장치는, 상기 UI 상에서 사용자 입력을 수신할 수 있다. 다른 일 실시예에 따라, 발신자 장치는 착신 전환에 대한 사용자 설정을 식별할 수 있다.
동작(915)에서, 발신자 장치는 호의 유지 여부를 결정할 수 있다. 발신자 장치는 사용자 입력 또는 미리 정의된 사용자 설정에 기반하여 호의 유지 여부를 결정할 수 있다. 상기 호는 보안 호를 위한 세션을 의미한다. 호를 유지하는 경우, 발신자 장치는 동작(909)을 수행할 수 있다. 호를 유지하지 않는 경우, 발신자 장치는 동작(917)을 수행할 수 있다.
동작(917)에서, 발신자 장치는 호를 종료할 수 있다. 일 실시예에 따라, 발신자 장치는 SIP 200 응답의 미수신에 기반하여, 호의 종료를 수행할 수 있다. 예를 들면, SIP 200 응답 수신 전에, 발신자 장치는, 발신자 장치의 강제 종료 입력을 수신할 수 있다. 다른 예를 들면, SIP 200 응답이 수신 전에, 발신자 장치는, 수신자 장치의 에러 응답, 혹은 실패 응답을 수신할 수 있다. 일 실시예에 따라, 발신자 장치는 호를 유지하지 않기로 결정하는 것에 기반하여, 호의 종료를 수행할 수 있다. 발신자 장치는, 발신자 요구에 따른 수신자 인증을 위한 최소 조건이 충족되지 않으므로, 호의 종료를 수행할 수 있다.
도 9b는 본 개시의 실시예에 따른, SIP에서 수신자 인증을 요청하는 호 연결을 위한 수신자 장치의 동작 흐름을 도시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 9b를 참조하면, 동작(951)에서, 수신자 장치는 인증 SIP INVITE 메시지를 수신할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(953)에서, 수신자 장치는 SIP 180 응답을 전송할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 인증 INVITE 메시지의 수신에 대한 응답으로 수신자 장치는 인증 설정을 결정할 수 있다. 인증 INVITE 메시지의 수신에 대한 응답으로 수신자 장치는 착신 전환 설정을 결정할 수 있다.
일 실시예에 따라, SIP 180 응답은, 인증 SIP INVITE 메시지의 수신에 대응하여, 발신자 요구에 따른 수신자 인증의 지원 여부를 가리킬 수 있다. 수신자 인증이란, 수신자 장치에서 사용자 인증을 의미한다. 상기 수신자 장치가 세션 설립 전 인증 기능을 지원하는지 여부 및 상기 수신자 장치에 인증 방법이 설정되었는지 여부에 기반하여, SIP 응답 메시지를 생성할 수 있다. 상기 수신자 장치는, 상기 수신자 장치에 인증 방법이 설정되고, 상기 수신자 장치가 수신자 인증의 기능을 지원하는 경우, 인증 상태를 포함하는 SIP 응답 메시지를 생성할 수 있다. 인증 상태는 '인증 지원'을 가리킬 수 있다.
상기 수신자 장치는, 상기 수신자 장치에 인증 방법이 설정되지 않거나, 상기 수신자 장치가 수신자 인증의 기능을 지원하지 않는 경우, 인증 상태를 포함하지 않는 SIP 응답 메시지를 생성할 수 있다. 발신자 장치는 지정된 헤더 필드(예: 호 정보('Call-info' 필드)에 어떠한 정보도 포함되지 않음을 식별하는 것에 기반하여, 수신자 장치가 인증을 지원하지 않음을 식별할 수 있다.
동작(955)에서, 수신자 장치는 착신 전환이 상기 수신자 장치에 설정되었는지 여부를 식별할 수 있다. 수신자 장치는 상기 수신자 장치에 착신 전환이 설정되지 않은 경우, 동작(957)을 수행할 수 있다. 수신자 장치는 상기 수신자 장치에 착신 전환이 설정된 경우, 동작(967)을 수행할 수 있다. 착신 전환이 활성화된 경우, 수신자 장치는 인증 방법이 있는 전자 장치(혹은 단말)만 선택하여 착신 전환할 수 있다. 착신 전환이 설정되지 않은 경우, 수신자 장치는 인증 지원을 가리키는 정보를 포함하는 SIP 180 응답 메시지를 전송할 수 있다.
동작(957)에서, 수신자 장치는 호 수락 여부를 식별할 수 있다. 수신자 장치는, 호 수락 여부를 식별하기 위하여, 호 수락 또는 호 거부를 가리키는 사용자 입력이 수신되는지 여부를 식별할 수 있다. 수신자 장치는 호가 수락되는 경우, 동작(959)을 수행할 수 있다. 수신자 장치는 호가 수락되지 않는 경우, 동작(971)을 수행할 수 있다.
동작(959)에서, 수신자 장치는 인증 요청 절차를 개시할 수 있다. 인증 요청 절차란, 발신자 요구에 따른 수신자 인증을 의미한다. 수신자 장치는 수신자 장치의 사용자에게 인증을 요청할 수 있다. 수신자 장치는, 지정된 사용자 입력을 요구하는 사용자 인터페이스를 표시할 수 있다. 예를 들어, 지정된 사용자 입력은 지문 인식을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 비밀번호를 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 홍채 인식을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 패턴을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 얼굴 인식을 포함할 수 있다. 수신자 장치는, 사용자 인터페이스 상에서 수신되는 사용자 입력을 수신할 수 있다. 도 9b에서는, 수신자 장치의 사용자가 통화를 수락하는 경우에만, 수신자 장치가 사용자에게 인증을 요청하는 것으로 도시되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 수신자 장치의 사용자가 통화를 거부하기를 원하는 경우도, 수신자 장치는 사용자에게 인증을 요청할 수 있다.
동작(961)에서, 수신자 장치는 인증 요청의 성공 여부를 식별할 수 있다. 수신자 장치는, 인증 요청의 성공 여부를 식별하기 위해, 수신되는 사용자 입력이 지정된 입력인지 여부를 식별할 수 있다. 예를 들어, 수신자 장치는 인식된 지문이 저장된 지문 정보와 일치하는 경우, 인증 성공을 식별할 수 있다. 예를 들어, 수신자 장치는 인식된 얼굴이 저장된 얼굴 정보와 일치하는 경우, 인증 성공을 식별할 수 있다. 예를 들어, 수신자 장치는 인식된 홍채가 저장된 홍채 정보와 일치하는 경우, 인증 성공을 식별할 수 있다. 예를 들어, 수신자 장치는 입력된 비밀번호가 저장된 비밀번호와 일치하는 경우, 인증 성공을 식별할 수 있다. 예를 들어, 수신자 장치는 입력된 패턴이 저장된 패턴과 일치하는 경우, 인증 성공을 식별할 수 있다.
동작(963)에서, 수신자 장치는 SIP 200 응답을 전송할 수 있다. SIP 200 응답은 동작(951)의 인증 SIP INVITE 메시지의 세션의 연결 요청에 대한 성공을 가리킬 수 있다. 일 실시예에 따라 수신자 장치는, 인증 성공을 식별하는 것에 기반하여, SIP 200 응답을 전송할 수 있다. SIP 200 응답의 전송은, 수신자 장치에서의 인증 성공을 가리킬 수 있다. 즉, 발신자 장치는 SIP 200 응답의 수신을 통해, 발신자 장치에서 요구한 수신자 장치의 사용자의 인증이 성공적으로 완료되었음을 식별할 수 있다.
동작(965)에서, 수신자 장치는 세션 연결을 설립할 수 있다. 이후, 수신자 장치는 설립된 세션 연결을 통해 발신자 장치와 통신을 수행할 수 있다. 예를 들어, 수신자 장치는 발신자 장치와 VoIP 서비스에 따른 전화를 수행할 수 있다.
동작(967)에서, 수신자 장치는 대상 전자 장치를 확인할 수 있다. 착신 전환이 설정된 경우, 수신자 장치는 착신 전환의 대상 전자 장치를 확인할 수 있다. 세션은 보안 호와 관련되므로, 대상 전자 장치에서도 수신자 인증이 요구된다. 수신자 장치는, 착신 전환 설정에 따른, 하나 이상의 대상 전자 장치들을 식별할 수 있다. 수신자 장치는 하나 이상의 대상 전자 장치들 각각의 상태 설정을 확인할 수 있다. 상태 설정은, 해당 전자 장치에서 본 개시의 실시예들에 따른, 발신자 요구에 따른 수신자 인증이 가능한 상태인지를 나타낸다. 일 실시예에 따라, 수신자 장치는 하나 이상의 대상 전자 장치들 중에서, 인증 방법을 갖는 전자 장치를 식별할 수 있다.
동작(969)에서, 수신자 장치는 인증 설정을 수행할 수 있다. 수신자 장치는 착신 전환의 대상 전자 장치에 인증 설정을 수행할 수 있다. 인증 설정으로 인해, 대상 전자 장치는 동작(951) 내지 동작(965)에 따른 수신자 인증 절차를 수행할 수 있다.
동작(971)에서, 수신자 장치는 호를 종료할 수 있다. 일 실시예에 따라, 수신자 장치는 인증 실패에 기반하여, 호의 종료를 수행할 수 있다. 인증 실패는, 수신자 장치의 소유자가 수신자 장치를 제어하기 어려움을 나타낼 수 있다. 발신자가 요구하는 인증이 실패했기 때문에, 수신자 장치는 보안 호의 연결 절차를 더 이상 수행하기 어렵다. 수신자 장치는, 발신자 장치가 호를 종료하도록 연결 요청의 실패 혹은 에러를 알리는 SIP 응답 메시지를 생성할 수 있다. 한편, 도 9b에 도시된 바와 달리, 다른 일 실시예에 따라, 수신자 장치는, 발신자 장치가 호를 종료할 때까지 대기할 수 있다.
일 실시예에 따라, 수신자 장치는 호 거부에 기반하여, 호의 종료를 수행할 수 있다. 수신자 장치의 사용자가 호를 수락하지 않는 경우, 인증의 성공 여부와 무관하게, 수신자 장치는 호의 종료를 개시할 수 있다. 수신자 장치는 연결 요청의 실패 혹은 에러를 알리는 SIP 응답 메시지를 생성할 수 있다. 수신자 장치는 발신자 장치에게, SIP 응답 메시지를 전송할 수 있다.
도 9b에서는 SIP 180 응답의 전송 이후, 착신 전환 여부를 판단하는 것으로 도시되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 수신자 장치의 설정에 따라 동작(953)은 생략되거나, 동작(953)은 동작(955) 이후 수행될 수 있다.
수신자 장치에서 착신 전환이 활성화된 경우, 수신자 장치는 인증 방법이 있는 단말만 선택하여 착신 전환할 수 있다. 착신 전환이 없는 경우, 수신자 장치는 인증 지원 상태를 포함하는 SIP 180 응답 메시지를 전송할 수 있다. 수신자 장치의 사용자가 통화를 수락하거나 거부하기를 원한다는 결정에 대한 응답으로, 수신자 장치는 사용자에게 인증을 요청할 수 있다. 수신자 장치가 인증 방식을 지원하지 않는 것으로 판단되면, 발신자 장치는 발신자 장치의 사용자 선택에 따라 통화를 유지하거나 종료할 수 있다. 이하. 도 10a 및 도 10b를 통해, 발신자 요구에 따른 수신자 인증을 요구하는 보안 호와 착신 전환 기능이 통합된 처리 방법이 서술된다. 도 10a에서는 발신자 장치의 동작이, 도 10b에서는 수신자 장치의 동작이 서술된다. 착신 전환을 위한 추가 로직은 전자 장치(발신자 장치 또는 수신자 장치) 또는 네트워크 측에서 구현될 수 있다.
도 10a는 본 개시의 실시예에 따른, SIP에서 착신 전환 시 인증 절차를 위한 발신자 장치의 동작 흐름을 도시한다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다.
도 10a를 참조하면, 동작(1001)에서, 발신자 장치는 인증 SIP INVITE 메시지를 전송할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1003)에서, 발신자 장치는 SIP 180 응답 또는 SIP 181 응답을 수신할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. SIP 181 응답은 수신자 장치의 착신 전환을 가리킨다.
동작(1005)에서, 발신자 장치는 수신자 장치에서 착신 전환이 활성화되어 있는지 여부를 식별할 수 있다. 발신자 장치는 수신자 장치에서 착신 전환이 활성화된 경우, 동작(1011)을 수행할 수 있다. 발신자 장치는 수신자 장치가 착신 전환이 활성화되지 않은 경우, 동작(1007)을 수행할 수 있다.
동작(1007)에서, 발신자 장치는 수신자 장치가 발신자 요구에 따른 인증을 지원하는지 여부를 식별할 수 있다. 발신자 장치는 수신자 장치가 발신자 요구에 따른 인증을 지원하는 경우, 동작(1009)을 수행할 수 있다. 발신자 장치는 수신자 장치가 발신자 요구에 따른 인증을 지원하지 않는 경우, 동작(1013)을 수행할 수 있다.
동작(1009)에서, 발신자 장치는 보안 호 절차를 수행할 수 있다. 발신자 장치는 도 3 내지 도 9b를 통해 서술된 바와 같이, 보안 호 절차를 수행할 수 있다. 보안 호 절차란, 수신자 장치의 사용자의 인증에 따른 세션 연결 절차를 의미한다. 수신자 장치에서의 응답에 기반하여, 발신자 장치는 수신자 장치의 사용자의 인증 여부를 확인하고, 수신자 장치의 사용자가 인증된 경우에 세션 연결을 수행할 수 있다.
동작(1011)에서, 발신자 장치는 착신 전환에 대한 보안 설정을 확인할 수 있다. 발신자 장치는 보안 호에 대해서 착신 전환을 허용할지 여부를 나타내는 보안 설정을 확인할 수 있다. 일 실시예에 따라, 보안 설정은 착신 전환의 허용을 가리킬 수 있다. 발신자 장치는 착신 전환의 대상 전자 장치가 발신자 요구에 따른 수신자 인증을 지원하는지 여부에 기반하여, 세션 연결을 수행할지 종료할지 결정할 수 있다. 발신자 장치는, 착신 전환의 대상 전자 장치와 세션 연결의 종료 여부를 결정하기 위해, 동작(1007)을 수행할 수 있다. 도 10a에서는 착신 전환에 대한 보안 설정 확인 후, 동작(1007)을 수행하는 것으로 도시되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 다른 일 실시예에 다라, 발신자 장치는 착신 전환에 대한 보안 설정을 확인한 후, 동작(1015)을 바로 수행할 수 있다.
동작(1013)에서, 발신자 장치는 인증 미지원에 대한 보안 설정을 확인할 수 있다.
동작(1015)에서, 발신자 장치는 호 유지 여부를 결정할 수 있다. 발신자 장치는 사용자 입력 또는 미리 정의된 사용자 설정에 기반하여 호의 유지 여부를 결정할 수 있다. 상기 호는 보안 호의 세션 설립을 위한 연결을 의미한다. 호를 유지하는 경우, 발신자 장치는 동작(1009)을 수행할 수 있다. 호를 유지하지 않는 경우, 발신자 장치는 동작(1017)을 수행할 수 있다.
일 실시예에 따라, 발신자 장치는 착신 전환 알림에 대응하여, 통화 유지 또는 취소 여부를 결정할 수 있다. 예를 들어, 발신자 장치는 미리 정의된 설정에 따라, 착신 전환 알림을 수신하는 것에 대응하여, 통화를 종료할 수 있다. 다른 예를 들어, 발신자 장치는 착신 전환 알림을 수신하는 것에 대응하여, 사용자의 입력의 수신을 위한 UI를 표시할 수 있다. UI에 입력되는 사용자 입력에 따라, 발신자 장치는 통화를 유지하거나 통화를 취소할 수 있다.
동작(1017)에서, 발신자 장치는 호를 종료할 수 있다. 발신자 장치는, 발신자 장치는 호를 유지하지 않기로 결정하는 것에 기반하여, 호의 종료를 수행할 수 있다. 발신자 장치는, 발신자 요구에 따른 수신자 인증을 위한 최소 조건이 충족되지 않으므로, 호의 종료를 수행할 수 있다.
도 10b는 본 개시의 실시예에 따른, SIP에서 착신 전환 시 인증 절차를 위한 수신자 장치의 동작 흐름을 도시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 10b를 참조하면, 동작(1051)에서, 수신자 장치는 인증 SIP INVITE 메시지를 수신할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1053)에서, 수신자 장치는 착신 전환 설정을 확인할 수 있다. 수신자 장치는, 보안 호에 대한 착신 전환 설정을 결정할 수 있다. 착신 전환 설정은, 수신자 장치가 부재중인 경우를 대비하여, 수신자 장치로 수신된 전화(call)를 다른 장치로 전환하는 기능을 의미한다.
동작(1055)에서, 수신자 장치는 보안 호의 착신 전환 여부를 식별할 수 있다. 수신자 장치는 보안 호가 착신 전환되는 경우, 동작(1061)을 수행할 수 있다. 수신자 장치는 보안 호가 착신 전환되지 않는 경우, 동작(1057)을 수행할 수 있다. 즉, 수신자 장치는, 조건부 착신 전환이 활성화되었는지 여부를 식별할 수 있다. 장치는, 보안 호에 대한 착신 전환 설정을 결정할 수 있다.
동작(1057)에서, 수신자 장치는 착신 전환을 비활성화할 수 있다. 수신자 장치는, 보안 호에 대한 착신 전환이 수행되지 않으면, 착신 전환을 비활성화할 수 있다.
동작(1059)에서, 수신자 장치는 보안 호 절차를 진행할 수 있다. 수신자 장치는 도 3 내지 도 9b를 통해 서술된 바와 같이, 보안 호 절차를 수행할 수 있다. 보안 호 절차란, 수신자 장치의 사용자의 인증에 따른 세션 연결 절차를 의미한다. 수신자 장치의 인증 절차에 기반하여, 수신자 장치는 발신자 장치에게 세션 연결의 성공을 가리키는 SIP 응답 메시지를 전송할 수 있다.
동작(1061)에서, 수신자 장치는 대상 전자 장치의 상태를 확인할 수 있다. 대상 전자 장치의 상태는, 대상 전자 장치에서 본 개시의 실시예들에 따른 발신자 요구에 따른 수신자 인증을 지원하는 지 여부를 나타낼 수 있다. 일 실시예에 따라, 대상 전자 장치의 상태는 대상 전자 장치에서 인증 방법이 설정되었는지 여부를 가리킬 수 있다. 또한, 일 실시예에 따라, 대상 전자 장치의 상태는 대상 전자 장치에서 개시의 실시예들에 따른 발신자 요구에 따른 수신자 인증 기능을 지원하는지 여부를 가리킬 수 있다.
동작(1063)에서, 수신자 장치는 대상 전자 장치가 수신자 인증을 지원하는지 여부를 식별할 수 있다. 수신자 장치는 대상 전자 장치의 상태에 기반하여, 대상 전자 장치가 수신자 인증을 지원하는지 여부를 식별할 수 있다. 수신자 장치는, 착신 전환 수행 시, 인증 방식을 지원하는 전자 장치를 선택할 수 있다. 수신자 장치는, 대상 전자 장치가 수신자 인증을 지원하지 않는 경우, 동작(1057)을 수행할 수 있다. 착신 전환을 할 필요성이 낮기 때문이다. 수신자 장치는, 대상 전자 장치가 수신자 인증을 지원하는 경우, 동작(1059)을 수행할 수 있다. 수신자 장치는, 대상 전자 장치가 인증을 지원하기 때문에, 착신 전환을 비활성화할 필요가 없기 때문이다.
본 개시의 실시예들에 따른, 발신자 장치는 세션의 연결 요청을 전송할 때, 수신자 장치에게 사용자 인증을 요구한다. 한편, 수신자 장치에서 착신 전환 기능이 설정되어 있는지 여부 혹은 수신자 장치에서 발신자 요구에 따른 사용자 인증 기능을 지원하는지 여부에 대한 정보는 서버에서 관리될 수 있다. 각 전자 장치(혹은 UE(user equipment))의 능력이 서버에 의해 중앙 집중식으로 관리되는 다른 배치 유형에서도 본 개시의 실시예들이 적용될 수 있다. 수신자 인증이 요구되는 전화는 보안 호로 지칭될 수 있다. 서버는 보안 호의 서비스를 관리할 수 있다. 예를 들어, 각 전자 장치는 보안 호와 관련된 정보를 서버에 업데이트할 수 있다. 또한, 예를 들어, 각 전자 장치는 보안 호와 관련된 기능을 서버로부터 가져올 수 있다. 이하. 도 11a 및 도 11b를 통해, 서버 관리에 의한 보안 호 절차가 서술된다. 도 11a에서는 발신자 장치의 동작이, 도 11b에서는 수신자 장치의 동작이 서술된다.
도 11a는 본 개시의 실시예에 따른, SIP에서 능력 정보를 이용하는 인증 절차를 위한 발신자 장치의 동작 흐름을 도시한다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다.
도 11a를 참조하면, 동작(1101)에서, 발신자 장치는 서버로부터 능력 정보를 수신할 수 있다. 능력 정보는 수신자 장치에 대한 인증 지원과 관련된 정보를 포함할 수 있다. 일 실시예에 따라, 능력 정보는 수신자 장치가 인증 기능의 지원 여부를 가리킬 수 있다. 인증 기능은 발신자의 인증 INVITE 메시지의 수신에 대응하여 지정된 UI를 표시하는 것을 포함할 수 있다. 수신자 인증을 위하여, 수신 전화(incoming call)에 대하여, 수신자 장치는 통화가 설립되기 전에 사용자에게 인증을 요청하는 화면을 표시할 것이 요구되기 때문이다. 일 실시예에 따라, 능력 정보는 수신자 장치에 설정된 인증 방법과 관련된 정보를 포함할 수 있다. 능력 정보는 수신자 장치에 인증 방법이 설정되었는지 여부를 가리킬 수 있다. 수신자 장치에 인증 방법이 설정되지 않은 경우, 수신자 인증 자체가 진행되기 어렵기 때문이다.
동작(1103)에서, 발신자 장치는 수신자 장치가 인증을 지원하는지 여부를 식별할 수 있다. 여기서, 인증은 발신자 요구에 따른 수신자 장치에서의 사용자 인증을 의미한다. 발신자 장치는 수신자 장치가 인증을 지원하는 경우, 동작(1105)을 수행할 수 있다. 발신자 장치는 수신자 장치가 인증을 지원하지 않는 경우, 동작(1109)을 수행할 수 있다.
동작(1105)에서, 발신자 장치는 인증 SIP INVITE 메시지를 전송할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1107)에서, 발신자 장치는 보안 호 절차를 진행할 수 있다. 보안 호 절차란, 수신자 장치의 사용자의 인증에 따른 세션 연결 절차를 의미한다. 수신자 장치에서의 응답에 기반하여 수신자 장치의 사용자의 인증 여부를 확인하고, 수신자 장치의 사용자가 인증된 경우에 세션 연결을 수행할 수 있다.
동작(1109)에서, 발신자 장치는 인증 미지원을 표시할 수 있다. 발신자 장치의 사용자는, 인증을 지원하지 않는 수신자 장치에게 보안 호를 걸지 않을 수 있다. 발신자 장치의 사용자가 수신자 장치의 인증 미지원을 인지하도록, 발신자 장치는 인증을 지원하지 않는 수신자 장치가 인증 미지원임을 표시할 수 있다.
도 11b는 본 개시의 실시예에 따른, SIP에서 능력 정보를 이용하는 인증 절차를 위한 수신자 장치의 동작 흐름을 도시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 11b를 참조하면, 동작(1151)에서, 수신자 장치는 서버로부터 능력 정보를 수신할 수 있다. 능력 정보는 발신자 장치의 보안 호와 관련된 정보를 포함할 수 있다. 일 실시예에 따라, 능력 정보는 발신자 장치에서 발신자 요구에 따른 수신자 인증을 지원하는지 여부를 가리킬 수 있다. 발신자 장치는 인증 SIP INVITE 메시지에 인증 요청(authentication request)를 포함하여야 하므로, 발신자 장치를 위한 능력 정보가 요구된다. 일 실시예에 따라, 능력 정보는 발신자 장치의 착신 전환 정책을 포함할 수 있다. 착신 전환이 발생한 경우, 보안 호를 유지하지 않기로 정책이 설정된다면, 수신자 장치는 착신 전환의 대상 전자 장치에 대한 설정을 확인할 필요가 없다.
동작(1153)에서, 수신자 장치는 인증 SIP INVITE 메시지를 수신할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1155)에서, 수신자 장치는 SIP 180 응답을 전송할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 일 실시예에 따라, 수신자 장치는 SIP 180 응답을 전송하기 위하여, 인증 기능의 지원을 가리키는 SIP 180 응답 메시지를 생성할 수 있다. 수신자 장치는 동작(1151)에서 수신된 능력 정보에 기반하여, SIP 180 응답 메시지를 생성할 수 있다. 발신자 장치의 능력 정보에 기반하여, 수신자 장치에서 인증 기능을 지원함을 나타내기 위해 생성해야 하는 메시지의 포맷이 정의될 수 있다.
동작(1157)에서, 수신자 장치는 호 수락 여부를 결정할 수 있다. 수신자 장치는 호 수락을 결정하는 동작(1159)을 수행할 수 있다. 수신자 장치는 호를 거부하는 경우, 동작(1165)을 수행할 수 있다.
동작(1159)에서, 수신자 장치는 사용자 설정을 확인할 수 있다. 사용자 설정이란, 인증 요청에 대한 사용자 입력을 의미한다. 수신자 장치는 인증 방법을 식별할 수 있다. 수신자 장치는 사용자에게 인증 요청을 수행할 수 있다. 일 실시예에 따라, 수신자 장치는 사용자에게 인증을 요청하는 UI를 표시할 수 있다. 예를 들어, UI는 지문 인식을 위한 인증 영역을 포함할 수 있다. 또한, 예를 들어, UI는 홍채 인식을 위한 인증 영역을 포함할 수 있다. 또한, 예를 들어, UI는 비밀번호 입력을 위한 화면을 포함할 수 있다. 또한, 예를 들어, UI는 패턴 입력을 위한 화면을 포함할 수 있다. 수신자 장치는, 인증 요청에 따른 사용자 설정을 확인할 수 있다.
동작(1161)에서, 수신자 장치는 인증 성공 여부를 식별할 수 있다. 일 실시예에 따라, 수신자 장치는 사용자 설정에 기반하여 인증 성공 여부를 식별할 수 있다. 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 지문 입력이 저장된 지문 정보와 일치하는지 여부를 식별할 수 있다. 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 비밀번호 입력이 저장된 비밀번호 정보와 일치하는지 여부를 식별할 수 있다. 또 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 홍채 입력이 저장된 홍채 정보와 일치하는지 여부를 식별할 수 있다. 또 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 패턴 입력이 저장된 패턴 정보와 일치하는지 여부를 식별할 수 있다. 다른 일 실시예에 따라, 수신자 장치(1230)는 인증 타이머(예: 도 13의 타이머)의 만료 여부에 기반하여 인증 성공을 식별할 수 있다. 수신자 장치(1230)는 타이머가 만료 전이라면, 현재 유효한 인증 결과가 존재함을 결정할 수 있다. 수신자 장치(1230)는 현재 유효한 인증 결과가 존재하는 바, 인증 성공을 식별할 수 있다.
동작(1163)에서, 수신자 장치는 보안 호 절차를 진행할 수 있다. 보안 호 절차란, 수신자 장치의 사용자의 인증에 따른 세션 연결 절차를 의미한다. 수신자 장치의 인증 절차에 기반하여, 수신자 장치는 발신자 장치에게 세션 연결의 성공을 가리키는 SIP 응답 메시지를 전송할 수 있다.
동작(1165)에서, 수신자 장치는 호를 종료할 수 있다. 일 실시예에 따라, 수신자 장치는 호 거절 입력을 수신할 수 있다. 수신자 장치의 사용자는 호를 수락하지 않을 수 있다. 이러한 경우, 수신자 장치는, 인증의 성공 여부와 상관없이, 호를 종료할 수 있다. 일 실시예에 따라, 수신자 장치는 인증 실패에 기반하여, 호의 종료를 수행할 수 있다. 인증 실패는, 수신자 장치의 소유자가 수신자 장치를 제어하기 어려움을 나타낼 수 있다. 발신자가 요구하는 인증이 실패했기 때문에, 수신자 장치는 보안 호의 연결 절차를 더 이상 수행하기 어렵다. 수신자 장치는, 발신자 장치가 호를 종료하도록 연결 요청의 실패 혹은 에러를 알리는 SIP 응답 메시지를 생성할 수 있다. 한편, 도 11에 도시된 바와 달리, 다른 일 실시예에 따라, 수신자 장치는, 발신자 장치가 호를 종료할 때까지 대기할 수 있다.
도 3 내지 도 11b에서는 보안 호를 요청하기 위해 인증 SIP INVITE 메시지가 서술되었다. 인증 SIP INVITE 메시지를 생성하기 위해, 발신자 장치는 SIP INVITE 메시지에 인증 요청을 위한 정보를 포함시켰다. 그러나, 다른 일 실시예에 따라, 인증 SIP INVITE 메시지는 서버에 의해 생성될 수도 있다. 이하, 도 12를 통해 서버가 인증 절차를 개시하기 위한 방안이 서술된다.
도 12는 본 개시의 실시예에 따른, SIP에서 서버를 이용하는 인증 절차를 위한 시그널링의 예를 도시한다. 수신자의 전자 장치는 MT(mobile termination)으로서, 수신자 장치로 지칭될 수 있다. 발신자의 전자 장치는 MO(mobile originator)로서, 발신자 장치로 지칭될 수 있다. 수신자 장치 및 발신자 장치는 전자 장치(101)를 예시한다. 발신자 장치와 수신자 장치 사이에서 메시지를 중계하기 위한 네트워크 엔티티로서, 서버가 이용될 수 있다.
도 12를 참조하면, 발신자 장치(1210)는 수신자 장치(1230)에게 전화를 걸 수 있다. 이 때, 본 개시의 실시예들에 따른 수신자 인증 요청은 서버(1220)에서 수행될 수 있다.
동작(S1201)에서, 발신자 장치(1210)는 서버에 등록을 수행할 수 있다. 발신자 장치(1210)는 발신자 장치(1210)를 서버에 등록할 수 있다. 발신자 장치(1210)는 발신자 장치(1210)의 서비스를 서버에 등록할 수 있다. 발신자 장치(1210)는 발신자 장치(1210)의 상태를 서버에 등록할 수 있다. 일 실시예에 따라, 발신자 장치(1210)는 특정 수신자 장치(예: 수신자 장치(1230))로의 호 연결 요청 시, 인증이 필요함을 나타내는 정보를 서버에 등록할 수 있다. 일 실시예에 따라, 발신자 장치(1210)는 보안 호의 연결 요청 시, 인증이 필요함을 나타내는 정보를 서버에 등록할 수 있다. 보안 호인지 여부에 대한 판단이 서버에 의해 수행될 수 있도록, 발신자 장치(1210)는 보안 호의 유형과 관련된 정보를 서버에 등록할 수 있다.
동작(S1203)에서, 발신자 장치(1210)는 SIP INVITE 메시지를 전송할 수 있다. 발신자 장치(1210)는 수신자 장치에게 전화를 걸기 위해, SIP INVITE 메시지를 전송할 수 있다. 발신자 장치(1210)의 SIP INVITE 메시지는 인증 요청을 포함하지 않을 수 있다. 도 12에서는 서버에 의해 인증 요청이 개시되는 바, 발신자 장치(1210)는 별도의 인증 요청 정보의 삽입 없이 SIP INVITE 메시지를 전송할 수 있다.
동작(S1211)에서, 서버(1220)는 서비스 관리 업데이트를 수행할 수 있다. 서버(1222)는 동작(S1201)의 등록에 대응하여, 발신자 장치(1210)를 위한 서비스 관리 업데이트를 수행할 수 있다.
동작(S1213)에서, 서버(1220)는 등록 서비스를 확인할 수 있다. 서버(1220)는 발신자 장치(1210)로부터 수신되는 SIP INVITE 메시지로부터 등록 서비스를 확인할 수 있다. 서버(1220)는 SIP INVITE 메시지에 기반하여, 발신자 장치(1210)의 등록 서비스가 수신자 인증을 요하는지 여부를 식별할 수 있다. 발신자 장치(1210)의 등록 서비스인 수신자 장치(1230)로의 호 연결이 수신자 인증을 요한다면, 서버(1220)는 수신자 인증을 요청할 것을 결정할 수 있다. 서버(1220)는 발신자 장치(1210)로부터 보안 호가 요청됨을 식별할 수 있다.
동작(S1215)에서, 서버(1220)는 인증 플래그를 삽입할 수 있다. 서버(1220)는 SIP INVITE 메시지를 재작성할 수 있다. 서버(1220)는 발신자 장치(1210)로부터 수신되는 SIP INVITE 메시지에 인증 플래그를 삽입할 수 있다. 일 실시예에 따라, 인증 플래그는 이미 존재하는 헤더(예: Call-info) 또는 보안 호를 위해 새로이 정의되는 헤더에 추가될 수 있다.
동작(S1217)에서, 서버(1220)는 보안 호 절차를 수행할 수 있다. 서버(1220)는 인증 플래그가 삽입된 SIP INVITE 메시지, 즉 인증 SIP INIVTE 메시지를 수신자 장치(1230)에게 전송할 수 있다. 서버(1220)는 수신자 장치의 사용자에게 인증을 요청하기 위해, 인증 SIP INVITE 메시지를 전송할 수 있다.
동작(S1221)에서, 수신자 장치(1230)는 인증 요청을 수행할 수 있다. 수신자 장치(1230)는 사용자에게 인증 요청을 수행할 수 있다. SIP INVITE 인증 수신에 대한 응답으로, 수신자 장치(1230)는 사용자에게 통화 수락을 위한 인증을 요청할 수 있다. 일 실시예에 따라, 수신자 장치(1230)는 사용자에게 인증을 요청하는 UI를 표시할 수 있다. 또한, 일 실시예에 따라, 수신자 장치(1230)는 현재 유효한 인증 결과가 존재하는지 여부를 식별할 수 있다.
동작(S1223)에서, 수신자 장치(1230)는 인증 성공을 식별할 수 있다. 일 실시예에 따라, 수신자 장치는 UI에서 지정된 입력을 수신하는 경우, 인증 성공을 식별할 수 있다. 지정된 입력이란 수신자 장치(1230) 혹은 수신자 장치(1230)와 연결된 네트워크에 저장된 정보와 일치하는 입력을 의미한다. 일 실시예에 따라, 수신자 장치(1230)는 인증 타이머(예: 도 13의 타이머)의 만료 여부에 기반하여 인증 성공을 식별할 수 있다. 수신자 장치(1230)는 타이머가 만료 전이라면, 현재 유효한 인증 결과가 존재함을 결정할 수 있다. 수신자 장치(1230)는 현재 유효한 인증 결과가 존재하는 바, 인증 성공을 식별할 수 있다.
동작(S1230)에서, 수신자 장치(1230)는 발신자 장치(1210)와 세션 설립을 수행할 수 있다. 수신자 장치(1230)는 인증 성공에 대응하여, 세션의 연결 요청의 성공을 가리키는 SIP 응답 메시지(예: SIP 200 OK)를 발신자 장치(1210)에게 전송할 수 있다. 발신자 장치(1210)는, SIP 응답 메시지를 수신한 것에 대한 응답으로, 확인 메시지를 수신자 장치(1230)에게 전송할 수 있다. 이후, 서버(1220)를 통해, 발신자 장치(1210) 및 수신자 장치(1230) 간 미디어 세션이 설립될 수 있다.
도 13은 본 개시의 실시예에 따른, 타이머(timer)를 이용하는 발신자 요구 기반 인증을 위한 수신자 장치의 동작 흐름을 도시한다. 도 13에서는, 수신자 장치에서 인증 동작을 최적화하기 위해 타이머를 운용하는 방안이 서술된다. 마지막 인증의 성공 이후 지정된 시간(예: 타이머의 길이) 내에 보안 호가 오면, 수신자 장치는 인증 요청을 건너뛸 수 있다. 타이머는 반복되는 인증 절차로 인한 오버헤드를 줄이기 위해 이용될 수 있다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 13을 참조하면, 동작(1301)에서, 수신자 장치는 타이머를 설정할(set) 수 있다. 타이머는 인증의 성공에 기반하여 설정될 수 있다. 여기서, 설정의 의미는 타이머를 개시(혹은 트리거)하는 것을 의미한다. 일 실시예에 따라, 수신자 장치는, 수신자 장치의 사용자의 인증의 성공을 식별하는 것에 기반하여, 타이머를 설정할 수 있다. 한 회의 인증이 성공되면, 타이머가 동작할 수 있다. 또한, 일 실시예에 따라, 수신자 장치는, 수신자 인증을 요하는 보안 호의 완료 후(다시 말해, 보안 호를 위한 세션 설립 후 종료 후), 타이머를 설정할 수 있다.
동작(1303)에서, 수신자 장치는 인증 SIP INVITE 메시지를 수신할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. SIP INVITE 메시지에 포함되는 인증 플래그는, 수신자 장치에서 사용자 인증을 요구할 수 있다.
동작(1305)에서, 수신자 장치는 SIP 180 응답을 전송할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 일 실시예에 따라, SIP 180 응답은, 인증 SIP INVITE 메시지의 수신에 대응하여, 발신자 요구에 따른 수신자 인증의 지원 여부를 가리킬 수 있다.
동작(1307)에서, 수신자 장치는 호 수락 여부를 결정할 수 있다 수신자 장치는, 호 수락 여부를 식별하기 위하여, 호 수락 또는 호 거부를 가리키는 사용자 입력이 수신되는지 여부를 식별할 수 있다. 수신자 장치는 호가 수락되는 경우, 동작(1309)을 수행할 수 있다. 수신자 장치는 호가 수락되지 않는 경우, 동작(1317)을 수행할 수 있다.
동작(1309)에서, 수신자 장치는 타이머의 만료 여부를 식별할 수 있다. 수신자 장치는, 사용자가 수신 전화를 수락한다는 결정(즉, 호의 수락 입력)에 응답하여 타이머의 만료 여부를 식별할 수 있다. 수신자 장치는, 타이머가 만료되지 않은 경우, 인증 요청을 건너뛰고 통화를 수락할 수 있다. 타이머가 만료되지 전이라면, 수신자 장치는 유효한 인증 결과를 저장할 수 있다. 수신자 장치는 인증 요청에 대하여, 유효한 인증 결과를 이용할 수 있다. 한편, 타이머의 만료는 유효한 인증 결과가 폐기됨을 의미할 수 있다. 수신자 장치는 타이머가 만료되면, 동작(S1313)을 수행할 수 있다. 수신자 장치는 타이머가 만료되지 않으면, 동작(S1311)을 수행할 수 있다.
동작(1311)에서, 수신자 장치는 보안 호 절차를 수행할 수 있다. 수신자 장치는 도 3 내지 도 9b를 통해 서술된 바와 같이, 보안 호 절차를 수행할 수 있다. 보안 호 절차란, 수신자 장치의 사용자의 인증에 따른 세션 연결 절차를 의미한다. 수신자 장치의 인증 절차에 기반하여, 수신자 장치는 발신자 장치에게 세션 연결의 성공을 가리키는 SIP 응답 메시지를 전송할 수 있다.
동작(1313)에서, 수신자 장치는 인증 요청을 수행할 수 있다. 수신자 장치는 사용자에게 인증 요청을 수행할 수 있다. 일 실시예에 따라, 수신자 장치는 사용자에게 인증을 요청하는 UI를 표시할 수 있다. 예를 들어, UI는 지문 인식을 위한 인증 영역을 포함할 수 있다. 또한, 예를 들어, UI는 홍채 인식을 위한 인증 영역을 포함할 수 있다. 또한, 예를 들어, UI는 비밀번호 입력을 위한 화면을 포함할 수 있다. 또한, 예를 들어, UI는 패턴 입력을 위한 화면을 포함할 수 있다. 수신자 장치는, 인증 요청에 따른 사용자 설정을 확인할 수 있다.
동작(1315)에서, 수신자 장치는 인증 성공 여부를 식별할 수 있다. 일 실시예에 따라, 수신자 장치는 사용자 설정에 기반하여 인증 성공 여부를 식별할 수 있다. 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 지문 입력이 저장된 지문 정보와 일치하는지 여부를 식별할 수 있다. 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 비밀번호 입력이 저장된 비밀번호 정보와 일치하는지 여부를 식별할 수 있다. 또 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 홍채 입력이 저장된 홍채 정보와 일치하는지 여부를 식별할 수 있다. 또 다른 예를 들어, 수신자 장치는 인증 성공 여부를 식별하기 위해, 사용자 설정에 따른 패턴 입력이 저장된 패턴 정보와 일치하는지 여부를 식별할 수 있다.
동작(1317)에서, 수신자 장치는 호를 종료할 수 있다. 일 실시예에 따라, 수신자 장치는 동작(1307)에서 호 거절 입력을 수신할 수 있다. 수신자 장치의 사용자는 호를 수락하지 않을 수 있다. 수신자 장치는, 인증의 성공 여부와 상관없이, 호를 종료할 수 있다. 일 실시예에 따라, 수신자 장치는 동작(1305)의 인증 실패에 기반하여, 호의 종료를 수행할 수 있다. 인증 실패는, 수신자 장치의 소유자가 수신자 장치를 제어하기 어려움을 나타낼 수 있다. 발신자가 요구하는 인증이 실패했기 때문에, 수신자 장치는 보안 호의 연결 절차를 더 이상 수행하기 어렵다.
수신자 장치에서의 사용자 인증 뿐만 아니라, 발신자 장치와 수신자 장치 간의 지정된 프로토콜에 따른 암호가 이용될 수 있다. 일 실시예에 따라, 수신자 장치가 인증 방법을 설정하지 않은 경우, 보안 호의 처리 방법을 위해 암호가 이용될 수 있다. 다른 일 실시예에 따라, 수신자 장치의 사용자 인증에 더하여, 암호가 추가적으로 이용될 수 있다. 이하. 도 14a 및 도 14b를 통해, 서버 관리에 의한 보안 호 절차가 서술된다. 도 14a에서는 발신자 장치의 동작이, 도 14b에서는 수신자 장치의 동작이 서술된다.
도 14a는 본 개시의 실시예에 따른, 암호(passcode)를 이용하는 발신자 요구 기반 인증을 위한 발신자 장치의 동작 흐름을 도시한다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다.
도 14a를 참조하면, 동작(1401)에서, 발신자 장치는 인증 SIP INVITE 메시지를 전송할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1403)에서, 발신자 장치는 SIP 180 응답을 수신할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 일 실시예에 따라, SIP 180 응답은, 인증 SIP INVITE 메시지의 수신에 대응하여, 발신자 요구에 따른 수신자 인증의 지원 여부를 가리킬 수 있다. 수신자 인증이란, 수신자 장치에서 사용자 인증을 의미한다. 일 실시예에 따라, SIP 180 응답은 인증 지원을 가리키는 헤더 필드를 포함할 수 있다.
동작(1405)에서, 발신자 장치는 SIP 200 응답을 수신할 수 있다. SIP 200 응답은 세션의 연결 요청이 성공임을 가리킨다. 일 실시예에 따라, SIP 200 응답은 암호를 포함할 수 있다. 일 실시예에 따라, 수신자 장치는 미리 지정된 프로토콜에 따라, 인증 성공 시, 암호를 포함하는 SIP 200 응답을 발신자 장치에게 전송할 수 있다. 발신자 장치는 SIP 200 응답을 수신하면, 발신자 장치는, 수신자 장치의 사용자 인증이 성공임을 식별할 수 있다. 발신자 장치는 추가적으로, 암호의 일치 여부를 판단하기 위해, 동작(1407)을 수행할 수 있다. 다른 일 실시예에 따라, 수신자 장치는, 수신자 장치에 인증 방법이 설정되지 않은 경우, 예비적으로 암호를 이용할 수 있다. 수신자 장치는 수신되는 암호 입력을 SIP 200 응답에 포함시킬 수 있다. SIP 200 응답이 수신되면, 발신자 장치는 수신자의 인증을 위해, 동작(1407)을 수행할 수 있다.
동작(1407)에서, 발신자 장치는 SIP 200 응답에 포함된 암호가 저장된 암호와 동일한지 여부를 식별할 수 있다. 발신자 장치는 SIP 200 응답에 포함된 암호가 저장된 암호와 동일한 경우, 동작(1409)을 수행할 수 있다. 발신자 장치는 SIP 200 응답에 포함된 암호가 저장된 암호와 동일하지 않은 경우, 동작(1411)을 수행할 수 있다.
동작(1409)에서, 발신자 장치는 보안 호 절차를 수행할 수 있다. 수신자 장치에서의 응답에 기반하여, 발신자 장치는 수신자 장치의 사용자의 인증 여부를 확인하고, 수신자 장치의 사용자가 인증된 경우에 세션 연결을 수행할 수 있다.
동작(1411)에서, 발신자 장치는 호를 종료할 수 있다. 암호의 불일치는 보안 조건이 충족되지 않음을 의미한다. 발신자 장치는 호를 유지하지 않기로 결정할 수 있다. 발신자 장치는, 발신자 장치는 호를 유지하지 않기로 결정하는 것에 기반하여, 호의 종료를 수행할 수 있다. 발신자 장치는, 수신자 인증이 성공하더라도, 수신자 장치의 암호가 저장된 암호와 일치하지 않으므로, 호의 종료를 수행할 수 있다.
도 14b는 본 개시의 실시예에 따른, 암호를 이용하는 발신자 요구 기반 인증을 위한 수신자 장치의 동작 흐름을 도시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 14b를 참조하면, 동작(1451)에서, 수신자 장치는 인증 SIP INVITE 메시지를 수신할 수 있다. 인증 SIP INVITE 메시지란, 인증 플래그가 포함된 SIP INVITE 메시지를 의미한다. 일 실시예에 따라, SIP INVITE의 헤더 필드는 인증 요구(authentication required)(또는 인증 요청(authentication request))를 가리키는 정보를 포함할 수 있다.
동작(1453)에서, 수신자 장치는 SIP 180 응답을 전송할 수 있다. SIP 180 응답은, 수신자 장치에서 벨이 울림을 가리킨다. 일 실시예에 따라, 수신자 장치는 SIP 180 응답을 전송하기 위하여, 인증 기능의 지원을 가리키는 SIP 180 응답 메시지를 생성할 수 있다. 수신자 장치는 동작(1151)에서 수신된 능력 정보에 기반하여, SIP 180 응답 메시지를 생성할 수 있다. 발신자 장치의 능력 정보에 기반하여, 수신자 장치에서 인증 기능을 지원함을 나타내기 위해 생성해야 하는 메시지의 포맷이 정의될 수 있다.
동작(1455)에서, 수신자 장치는 호 수락에 대응하여 암호 입력을 수신할 수 있다. 수신자 장치는 호 수락 시, 발신자 요구에 따른 인증을 위한 암호 입력의 수신을 기대할 수 있다. 수신자 장치는 암호 입력을 위한 UI를 표시할 수 있다. 수신자 장치는 UI를 통해 암호 입력을 수신할 수 있다. 도 14b 내에는 도시되지 않았으나, 수신자 장치는 호 수락 시, 인증 절차와 함께 암호 입력 절차가 이용될 수 있다. 2-단계 인증을 위해, 도 3 내지 도 13에 서술된 사용자 인증 요청과 발신자 확인을 위한 암호 입력 절차가 함께 수행될 수 있다.
동작(1457)에서, 수신자 장치는 암호를 포함하는 SIP 200 응답을 전송할 수 있다. 일 실시예에 따라, 수신자 장치가 인증 방법을 설정하지 않은 경우, 보안 호의 처리 방법을 위해 암호가 이용될 수 있다. 인증 INVITE 메시지의 수신에 대응하여, 수신자 장치는 암호를 수신하기 위한 인증 설정을 결정할 수 있다. 사용자의 호 수락에 대한 응답으로, 수신자 장치는 사용자로부터 입력된 암호를 SIP 200 응답과 함께 전송할 수 있다. 다른 일 실시예에 따라, 수신자 장치의 추가적인 보안을 위해, 수신자 장치에서 인증이 성공한 경우, 암호가 추가적으로 이용될 수 있다. 발신자 장치에게 최종 확인을 요청하기 위해, 수신자 장치는 사용자로부터 입력된 암호를 SIP 200 응답과 함께 전송할 수 있다.
도 15는 본 개시의 실시예에 따른, 화면 잠금(screen lock)에 따른 발신자 요구 기반 인증을 위한 발신자 장치 및 수신자 장치의 동작 흐름을 도시한다. 도 15에서의 SIP 메시지는 텍스트, 음성 또는 비디오를 제공하기 위한 SMS(short message service) 메시지를 포함할 수 있다. 발신자 장치는 도 3의 발신자 장치(310), 도 4의 발신자 장치(410), 또는 도 5의 발신자 장치(510)를 예시한다. 수신자 장치는 도 3의 수신자 장치(330), 도 4의 수신자 장치(430), 및 도 5의 제1 수신자 장치(531), 제2 수신자 장치(532), 제3 수신자 장치(533)를 예시한다.
도 15를 참조하면, 동작(1501)에서, 발신자 장치는 인증 헤더(authentication header)를 생성할 수 있다. 인증 헤더는, 인증 플래그가 설정되는 메시지의 헤더 필드를 의미할 수 있다. 발신자 장치는 수신자 장치에게 사용자 인증을 요청하기 위해, SIP 메시지 내 헤더 필드에 인증 플래그를 설정할 수 있다.
동작(1503)에서, 발신자 장치는 인증 SIP 메시지를 전송할 수 있다. 발신자 장치는 인증 SIP 메시지를 전송할 수 있다. 여기서, 인증 SIP 메시지란, 인증 플래그를 포함하는 SIP 메시지를 의미한다. 일 실시예에 따라, SIP 메시지는 SMS 메시지를 포함할 수 있다.
동작(1505)에서, 수신자 장치는 인증 SIP 메시지를 수신할 수 있다. 일 실시예에 따라, 인증 SIP 메시지는 수신자 인증이 요구되는 SMS 메시지를 포함할 수 있다.
동작(1507)에서, 수신자 장치는 화면 잠금에 메시지를 표시할지 여부를 식별할 수 있다. 수신자 장치는, 수신자 장치의 설정에 기반하여, 화면 잠금에 메시지를 표시할지 여부를 식별할 수 있다. 수신자 장치의 설정은, 잠금 화면(lock screen)에 메시지를 표시할 지 여부를 가리킬 수 있다. 수신자 장치는, 화면 잠금에 메시지를 표시할 경우, 동작(1509)을 수행할 수 있다. 수신자 장치는, 화면 잠금에 메시지를 표시하지 않을 경우, 동작(1513)을 수행할 수 있다.
동작(1509)에서, 수신자 장치는 SIP 메시지가 인증 헤더를 포함하는지 여부를 식별할 수 있다. 수신자 장치는 SIP 메시지가 인증 헤더를 포함하지 않은 경우, 동작(1513)을 수행할 수 있다. 수신자 장치는 SIP 메시지가 인증 헤더를 포함하는 경우, 동작(1511)을 수행할 수 있다.
동작(1511)에서, 수신자 장치는 인증 요청을 수행할 수 있다. 수신자 장치는 SMS 메시지 내용의 표시 여부를 식별하기 위해, 사용자에게 인증 요청을 수행할 수 있다. 수신자 장치는, 지정된 사용자 입력을 요구하는 사용자 인터페이스를 표시할 수 있다. 예를 들어, 지정된 사용자 입력은 지문 인식을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 비밀번호를 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 홍채 인식을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 패턴을 포함할 수 있다. 예를 들어, 지정된 사용자 입력은 얼굴 인식을 포함할 수 있다. 수신자 장치는, 사용자 인터페이스 상에서 수신되는 사용자 입력을 수신할 수 있다. 도 15에서는, 수신자 장치의 사용자가 통화를 수락하는 경우에만, 수신자 장치가 사용자에게 인증을 요청하는 것으로 도시되었으나, 본 개시의 실시예들은 이에 한정되지 않는다. 수신자 장치의 사용자가 통화를 거부하기를 원하는 경우도, 수신자 장치는 사용자에게 인증을 요청할 수 있다. 일 실시예에 따라, 수신자 장치는 사용자 인증이 성공한 경우, 메시지를 잠금 화면에 표시할 수 있다.
동작(1513)에서, 수신자 장치는 화면 잠금 해제 후 메시지를 표시할 수 있다. 수신자 장치의 잠금이 해제된 경우, 인증 SIP 메시지(예: 인증 SMS)는 일반 메시지로 처리될 수 있다. 수신자 장치가 잠금 화면에 메시지 내용을 표시하도록 설정되고, 사용자가 인증 메시지를 표시하도록 요청하면, 수신자 장치는 사용자에게 인증을 요청할 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)에 의해 수행되는 방법은, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하는 동작을 포함할 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함할 수 있다. 상기 방법은 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하는 동작을 포함할 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함할 수 있다. 상기 방법은 상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별하는 동작을 포함할 수 있다. 상기 방법은 상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하는 동작을 포함할 수 있다. 상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리킬 수 있다.
일 실시예에 따라, 상기 SIP 응답 메시지가 수신되는지 여부를 식별하는 동작은, 상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지를 상기 서버로부터 수신하는 동작을 포함할 수 있다. 일 실시예에 따라, 상기 SIP 응답 메시지가 수신되는지 여부를 식별하는 동작은, 상기 착신 전환에 대한 사용자 설정에 기반하여, 상기 대상 전자 장치로부터 상기 SIP 응답 메시지가 수신되는지 여부를 식별하는 동작을 포함할 수 있다.
일 실시예에 따라, 상기 사용자 설정은, 상기 착신 전환의 대상 전자 장치에게 상기 세션의 연결 요청을 허용할 것을 가리킬 수 있다.
일 실시예에 따라, 상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 180일 수 있다. 상기 착신 전환을 가리키기 위한 SIP 정보 메시지의 코드 번호는 181일 수 있다. 상기 SIP 응답 메시지의 코드 번호는 200일 수 있다.
일 실시예에 따라, 상기 방법은 상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지의 수신에 대응하여, 통화 종료를 가리키기 위한 사용자 입력을 수신하는 동작을 더 포함할 수 있다.
일 실시예에 따라, 상기 방법은 상기 사용자 입력에 대응하여, 상기 세션의 연결 요청의 종료를 요청하는 메시지를 상기 서버에게 전송하는 동작을 더 포함할 수 있다.
일 실시예에 따라, 상기 인증 요청은, 상기 다른 전자 장치 또는 상기 착신 전환의 대상 전자 장치에서의 지정된 사용자 입력을 요구할 수 있다. 상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 세션을 설립하는 동작은, 상기 SIP 응답 메시지에 포함되는 패스워드 정보를 식별하는 동작을 포함할 수 있다. 상기 세션을 설립하는 동작은 상기 패스워드 정보의 검증(validation) 결과에 기반하여, 상기 세션을 설립하는 동작을 포함할 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)에 의해 수행되는 방법은, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하는 동작을 포함할 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함할 수 있다. 상기 방법은 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하는 동작을 포함할 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함할 수 있다. 상기 방법은 상기 인증 요청에 따른 지정된 사용자 입력을 수신하는 동작을 포함할 수 있다. 상기 방법은 상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하는 동작을 포함할 수 있다.
일 실시예에 따라, 상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 181일 수 있다. 상기 SIP 응답 메시지의 코드 번호는 200일 수 있다.
일 실시예에 따라, 상기 지정된 사용자 입력을 수신하는 동작은, 상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하는 동작을 포함할 수 있다. 상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 SIP 응답 메시지는 상기 인증 요청에 대응하는 패스워드 정보를 포함할 수 있다.
일 실시예에 따라, 상기 사용자 입력을 수신하는 동작은, 인증 타이머의 만료를 식별하는 것에 기반하여, 상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하는 동작을 포함할 수 있다. 상기 인증 타이머는, 상기 인증 요청 이전에 수신된 다른 인증 요청에 따른 인증 성공 시 시작될 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)는, 메모리; 적어도 하나의 송수신기; 및 상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하도록 구성될 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하도록 구성될 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별할 수 있다. 상기 적어도 하나의 프로세서는, 상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하도록 구성될 수 있다. 상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리킬 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 SIP 응답 메시지가 수신되는지 여부를 식별하기 위해, 상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지를 상기 서버로부터 수신하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 SIP 응답 메시지가 수신되는지 여부를 식별하기 위해, 상기 착신 전환에 대한 사용자 설정에 기반하여, 상기 대상 전자 장치로부터 상기 SIP 응답 메시지가 수신되는지 여부를 식별하도록 구성될 수 있다.
일 실시예에 따라, 상기 사용자 설정은, 상기 착신 전환의 대상 전자 장치에게 상기 세션의 연결 요청을 허용할 것을 가리킬 수 있다.
일 실시예에 따라, 상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 180일 수 있다. 상기 착신 전환을 가리키기 위한 SIP 정보 메시지의 코드 번호는 181일 수 있다. 상기 SIP 응답 메시지의 코드 번호는 200일 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지의 수신에 대응하여, 통화 종료를 가리키기 위한 사용자 입력을 수신하도록 추가적으로 구성될 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 사용자 입력에 대응하여, 상기 세션의 연결 요청의 종료를 요청하는 메시지를 상기 서버에게 전송하도록 추가적으로 구성될 수 있다.
일 실시예에 따라, 상기 인증 요청은, 상기 다른 전자 장치 또는 상기 착신 전환의 대상 전자 장치에서의 지정된 사용자 입력을 요구할 수 있다. 상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 세션을 설립하기 위하여, 상기 SIP 응답 메시지에 포함되는 패스워드 정보를 식별할 수 있다. 상기 적어도 하나의 프로세서는, 상기 세션을 설립하기 위하여, 상기 패스워드 정보의 검증(validation) 결과에 기반하여, 상기 세션을 설립하도록 구성될 수 있다.
실시예들에 따를 때, 전자 장치(electronic device)는, 메모리; 적어도 하나의 송수신기; 및 상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함할 수 있다. 상기 적어도 하나의 프로세서는, 세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하도록 구성될 수 있다. 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함할 수 있다. 상기 적어도 하나의 프로세서는, 울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하도록 구성될 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함할 수 있다. 상기 적어도 하나의 프로세서는, 상기 인증 요청에 따른 지정된 사용자 입력을 수신하도록 구성될 수 있다. 상기 적어도 하나의 프로세서는, 상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하도록 구성될 수 있다.
일 실시예에 따라, 상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리킬 수 있다. 상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 181일 수 있다. 상기 SIP 응답 메시지의 코드 번호는 200일 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 지정된 사용자 입력을 수신하기 위해, 상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하도록 구성될 수 있다. 상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함할 수 있다.
일 실시예에 따라, 상기 SIP 응답 메시지는 상기 인증 요청에 대응하는 패스워드 정보를 포함할 수 있다.
일 실시예에 따라, 상기 적어도 하나의 프로세서는, 상기 사용자 입력을 수신하기 위해, 인증 타이머의 만료를 식별하는 것에 기반하여, 상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하도록 구성될 수 있다. 상기 인증 타이머는, 상기 인증 요청 이전에 수신된 다른 인증 요청에 따른 인증 성공 시 시작될 수 있다.
실시예들에 따른 전자 장치는 적어도 하나의 스피커와 적어도 하나의 마이크를 포함할 수 있다. 실시예들에 따른 전자 장치는 네트워크와 통신하기 위한 적어도 하나의 통신 회로를 포함할 수 있다. 실시예들에 따른 전자 장치는 스피커 및 마이크와 작동 가능하게 연결된 프로세서를 포함할 수 있다. 실시예들에 따른 전자 장치는 프로세서와 작동 가능하게 연결된 프로세서를 포함할 수 있다. 수신자 장치에는 하나 이상의 인증 서비스들이 설정될 수 있다. 발신자의 인증 요청에 대응하여, 수신자 장치에서는 인증 서비스가 제공될 수 있다.
본 개시의 실시예들은, IMS 서비스에서 세션 설립 전 인증 방법을 통해, 다양한 솔루션들을 제공할 수 있다. 일 실시예에 따라, 인증 방법은, 전자 장치의 변경만을 통해 달성될 수 있다. 일 실시예에 따라, 인증 방법은 OTT 애플리케이션을 위한 VoIP 서비스를 위해 이용될 수 있다. 일 실시예에 따라, 인증 방법은, 네트워크 솔루션으로서, 사업자의 새로운 서비스를 위해 이용될 수 있다. 일 실시예에 따라, 인증 방법은, 착신 전환 및 음성 메일 기능과의 통합을 제공할 수 있다. 일 실시예에 따라, 인증 방법은, IoT 환경에서 보안 호 서비스를 제공할 수 있다. 인증 방법은, CMC 기능(Call & Message Continuity)과 연동될 수 있다. 뿐만 아니라, 인증 방법에서, 발신자는 전화를 요청할 때(즉, 호를 위한 세션 설립 절차 중에), 수신자 인증을 요청하기 때문에, 발신자의 프라이버시를 보호하고, 설립될 세션의 신뢰도를 높일 수 있다.
상술한 바와 같은 논의를 바탕으로, 본 개시(disclosure)는, 세션 개시 프로토콜(session initial protocol, SIP)에서 인증(authentication)을 통해 세션 설립을 위한 장치 및 방법을 제공한다.
본 개시는 발신자의 필요(demand)에 따라 인증(authentication)을 요청하기 위한 통화 서비스를 위한 장치 및 방법을 제공한다.
본 개시는 편집 가능한(editable) 기존 헤더 필드(header field)를 이용하는 인증 절차를 제공하기 위한 장치 및 방법을 제공한다.
본 개시의 실시예들에 따른 장치 및 방법은, 세션 개시 프로토콜(session initial protocol, SIP)에서 수신자(callee)의 응답 메시지에 인증 상태가 제공됨으로써, 발신자(caller)의 요구(demand)에 따른 보안 수준으로 전화 서비스(call service)가 수행될 수 있다.
본 개시에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 개시의 청구항 또는 명세서에 기재된 실시예들에 따른 방법들은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합의 형태로 구현될(implemented) 수 있다.
소프트웨어로 구현하는 경우, 하나 이상의 프로그램(소프트웨어 모듈)을 저장하는 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장되는 하나 이상의 프로그램은, 전자 장치(device) 내의 하나 이상의 프로세서에 의해 실행 가능하도록 구성된다(configured for execution). 하나 이상의 프로그램은, 전자 장치로 하여금 본 개시의 청구항 또는 명세서에 기재된 실시예들에 따른 방법들을 실행하게 하는 명령어(instructions)를 포함한다.
이러한 프로그램(소프트웨어 모듈, 소프트웨어)은 랜덤 액세스 메모리 (random access memory), 플래시(flash) 메모리를 포함하는 불휘발성(non-volatile) 메모리, 롬(read only memory, ROM), 전기적 삭제가능 프로그램가능 롬(electrically erasable programmable read only memory, EEPROM), 자기 디스크 저장 장치(magnetic disc storage device), 컴팩트 디스크 롬(compact disc-ROM, CD-ROM), 디지털 다목적 디스크(digital versatile discs, DVDs) 또는 다른 형태의 광학 저장 장치, 마그네틱 카세트(magnetic cassette)에 저장될 수 있다. 또는, 이들의 일부 또는 전부의 조합으로 구성된 메모리에 저장될 수 있다. 또한, 각각의 구성 메모리는 다수 개 포함될 수도 있다.
또한, 프로그램은 인터넷(Internet), 인트라넷(Intranet), LAN(local area network), WAN(wide area network), 또는 SAN(storage area network)과 같은 통신 네트워크, 또는 이들의 조합으로 구성된 통신 네트워크를 통하여 접근(access)할 수 있는 부착 가능한(attachable) 저장 장치(storage device)에 저장될 수 있다. 이러한 저장 장치는 외부 포트를 통하여 본 개시의 실시예를 수행하는 장치에 접속할 수 있다. 또한, 통신 네트워크상의 별도의 저장장치가 본 개시의 실시예를 수행하는 장치에 접속할 수도 있다.
상술한 본 개시의 구체적인 실시예들에서, 개시에 포함되는 구성 요소는 제시된 구체적인 실시예에 따라 단수 또는 복수로 표현되었다. 그러나, 단수 또는 복수의 표현은 설명의 편의를 위해 제시한 상황에 적합하게 선택된 것으로서, 본 개시가 단수 또는 복수의 구성 요소에 제한되는 것은 아니며, 복수로 표현된 구성 요소라 하더라도 단수로 구성되거나, 단수로 표현된 구성 요소라 하더라도 복수로 구성될 수 있다.
한편 본 개시의 상세한 설명에서는 구체적인 실시예에 관해 설명하였으나, 본 개시의 범위에서 벗어나지 않는 한도 내에서 여러 가지 변형이 가능함은 물론이다.

Claims (14)

  1. 전자 장치(electronic device)에 의해 수행되는 방법에 있어서,
    세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하는 동작과, 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함하고,
    울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하는 동작과, 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함하고,
    상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별하는 동작과,
    상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하는 동작을 포함하고,
    상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리키는 방법.
  2. 청구항 1에 있어서, 상기 SIP 응답 메시지가 수신되는지 여부를 식별하는 동작은,
    상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지를 상기 서버로부터 수신하는 동작과,
    상기 착신 전환에 대한 사용자 설정에 기반하여, 상기 대상 전자 장치로부터 상기 SIP 응답 메시지가 수신되는지 여부를 식별하는 동작을 포함하는 방법.
  3. 청구항 1 내지 2에 있어서, 상기 사용자 설정은, 상기 착신 전환의 대상 전자 장치에게 상기 세션의 연결 요청의 허용을 가리키는 방법.
  4. 청구항 1 내지 3에 있어서,
    상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리키고,
    상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리키고,
    상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 180이고,
    상기 착신 전환을 가리키기 위한 SIP 정보 메시지의 코드 번호는 180이고,
    상기 SIP 응답 메시지의 코드 번호는 200인 방법.
  5. 청구항 1 내지 4에 있어서,
    상기 세션에 대한 착신 전환(call forwarding)을 가리키기 위한 SIP 정보 메시지의 수신에 대응하여, 통화 종료를 가리키기 위한 사용자 입력을 수신하는 동작과,
    상기 사용자 입력에 대응하여, 상기 세션의 연결 요청의 종료를 요청하는 메시지를 상기 서버에게 전송하는 동작을 더 포함하는 방법.
  6. 청구항 1 내지 5에 있어서,
    상기 인증 요청은, 상기 다른 전자 장치 또는 상기 착신 전환의 대상 전자 장치에서의 지정된 사용자 입력을 요구하고,
    상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함하는 방법.
  7. 청구항 1 내지 6에 있어서, 상기 세션을 설립하는 동작은,
    상기 SIP 응답 메시지에 포함되는 패스워드 정보를 식별하는 동작과,
    상기 패스워드 정보의 검증(validation) 결과에 기반하여, 상기 세션을 설립하는 동작을 포함하는 방법.
  8. 전자 장치(electronic device)에 의해 수행되는 방법에 있어서,
    세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하는 동작과, 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함하고,
    울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하는 동작과, 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함하고,
    상기 인증 요청에 따른 지정된 사용자 입력을 수신하는 동작과,
    상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하는 동작을 포함하는 방법.
  9. 청구항 8에 있어서,
    상기 SIP INVITE 메시지의 헤더(header)의 호 정보(call-information, Call-info) 필드는 상기 인증 요청을 가리키고,
    상기 울림을 가리키기 위한 SIP 정보 메시지는 상기 인증 지원을 가리키고,
    상기 울림을 가리키기 위한 SIP 정보 메시지의 코드 번호는 180이고,
    상기 SIP 응답 메시지의 코드 번호는 200인 방법.
  10. 청구항 8 내지 9에 있어서, 상기 지정된 사용자 입력을 수신하는 동작은,
    상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하는 동작을 포함하고,
    상기 지정된 사용자 입력은 패턴, 비밀번호, 지문 인식 결과, 얼굴 인식 결과, 홍채 인식 결과 중 적어도 하나를 포함하는 방법.
  11. 청구항 8 내지 10에 있어서, 상기 SIP 응답 메시지는 상기 인증 요청에 대응하는 패스워드 정보를 포함하는 방법.
  12. 청구항 8 내지 11에 있어서, 상기 사용자 입력을 수신하는 동작은,
    인증 타이머의 만료를 식별하는 것에 기반하여, 상기 지정된 사용자 입력을 위한 사용자 인터페이스(user interface)를 표시하는 동작을 포함하고,
    상기 인증 타이머는, 상기 인증 요청 이전에 수신된 다른 인증 요청에 따른 인증 성공 시 시작되는 방법.
  13. 전자 장치(electronic device)에 있어서,
    메모리;
    적어도 하나의 송수신기; 및
    상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함하고,
    상기 적어도 하나의 프로세서는,
    세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치에게 전송하고, 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 가리키는 정보를 포함하고,
    울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치로부터 수신하고, 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 가리키는 정보를 포함하고,
    상기 다른 전자 장치 또는 착신 전환(call forwarding)의 대상 전자 장치로부터 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지가 수신되는지 여부를 식별하고,
    상기 SIP 응답 메시지의 수신에 대응하여, 상기 세션을 설립하도록 구성되고,
    상기 SIP 응답 메시지의 수신은, 상기 인증 요청에 따른, 상기 다른 전자 장치 또는 상기 대상 전자 장치에서의 인증 성공을 가리키는 전자 장치.
  14. 전자 장치(electronic device)에 있어서,
    메모리;
    적어도 하나의 송수신기; 및
    상기 메모리 및 상기 적어도 하나의 송수신기와 결합되는 적어도 하나의 프로세서를 포함하고,
    상기 적어도 하나의 프로세서는,
    세션(session)의 연결 요청을 위한 SIP(session initiation protocol) 초대(INVITE) 메시지를 서버를 통해 다른 전자 장치로부터 수신하고, 상기 SIP INVITE 메시지는 인증 요청(authentication request)을 포함하고,
    울림(ringing)을 가리키기 위한 SIP 정보 메시지를 상기 서버를 통해 상기 다른 전자 장치에게 전송하고, 상기 울림을 가리키기 위한 SIP 정보 메시지는 인증 지원(authentication support)을 포함하고,
    상기 인증 요청에 따른 지정된 사용자 입력을 수신하고,
    상기 지정된 사용자 입력에 기반하여, 상기 연결 요청의 성공(success)을 가리키기 위한 SIP 응답(response) 메시지를 상기 다른 전자 장치에게 전송하도록 구성되는 전자 장치.
PCT/KR2023/001481 2022-05-02 2023-02-01 세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법 WO2023214643A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/171,054 US20230353565A1 (en) 2022-05-02 2023-02-17 Electronic device and method for authentication in session initiation protocol

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020220054489A KR20230154720A (ko) 2022-05-02 2022-05-02 세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법
KR10-2022-0054489 2022-05-02

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/171,054 Continuation US20230353565A1 (en) 2022-05-02 2023-02-17 Electronic device and method for authentication in session initiation protocol

Publications (1)

Publication Number Publication Date
WO2023214643A1 true WO2023214643A1 (ko) 2023-11-09

Family

ID=88646564

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2023/001481 WO2023214643A1 (ko) 2022-05-02 2023-02-01 세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법

Country Status (2)

Country Link
KR (1) KR20230154720A (ko)
WO (1) WO2023214643A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060225129A1 (en) * 2005-03-31 2006-10-05 Nec Infrontia Corporation Authentication system for authenticating communication terminal
KR20160002295A (ko) * 2014-06-30 2016-01-07 인비즈넷 주식회사 인바운드 콜을 이용한 인증에서 위조된 전화번호를 식별할 수 있는 인증시스템 및 그 방법
KR20160126388A (ko) * 2015-04-23 2016-11-02 삼성전자주식회사 전자 장치 및 전자 장치의 호 처리 방법
KR20200017307A (ko) * 2018-08-08 2020-02-18 삼성전자주식회사 전자 장치 및 그의 통신 중계 방법
US20210266750A1 (en) * 2017-10-18 2021-08-26 Telesign Corporation User authentication based on ss7 call forwarding detection

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060225129A1 (en) * 2005-03-31 2006-10-05 Nec Infrontia Corporation Authentication system for authenticating communication terminal
KR20160002295A (ko) * 2014-06-30 2016-01-07 인비즈넷 주식회사 인바운드 콜을 이용한 인증에서 위조된 전화번호를 식별할 수 있는 인증시스템 및 그 방법
KR20160126388A (ko) * 2015-04-23 2016-11-02 삼성전자주식회사 전자 장치 및 전자 장치의 호 처리 방법
US20210266750A1 (en) * 2017-10-18 2021-08-26 Telesign Corporation User authentication based on ss7 call forwarding detection
KR20200017307A (ko) * 2018-08-08 2020-02-18 삼성전자주식회사 전자 장치 및 그의 통신 중계 방법

Also Published As

Publication number Publication date
KR20230154720A (ko) 2023-11-09

Similar Documents

Publication Publication Date Title
WO2011056034A2 (en) Method for controlling session and server using the same
WO2020076110A1 (en) Electronic device for determining p2p operating channel and method thereof
WO2021241849A1 (ko) 에지 컴퓨팅 서비스를 수행하는 전자 장치 및 전자 장치의 동작 방법
WO2020032649A1 (en) Electronic device and communication relaying method thereof
WO2021201620A1 (en) Electronic device for performing edge computing service and method for the same
WO2022149874A1 (en) Method and system of authentication and authorization in an msgin5g server
WO2022005000A1 (en) Electronic device and method of operating the same
WO2023214643A1 (ko) 세션 개시 프로토콜에서 인증을 위한 전자 장치 및 방법
WO2022220584A1 (ko) 전자 장치 및 전자 장치에서 외부 전자 장치의 클라우드 온보딩을 수행하는 방법
WO2023003147A1 (ko) 전자 장치의 네트워크 락 기능을 설정하는 방법 및 그 전자 장치
WO2022231140A1 (ko) 장치 식별 정보를 송신 및/또는 수신하는 전자 장치 및 그 동작 방법
WO2022025463A1 (ko) 외부 장치들이 출력하는 컨텐츠의 출력 시점을 동기화하는 전자 장치 및 전자 장치의 동작 방법
WO2023182645A1 (ko) 스팸 통화를 탐지하는 전자 장치 및 그 동작 방법
WO2019172653A1 (ko) 보안 엘리먼트를 포함하는 전자 장치에서 수행하는 방법 및 전자 장치
WO2024014654A1 (ko) 통화 녹음을 수행하기 위한 전자 장치 및 그의 동작 방법
WO2022139131A1 (ko) 중복 메시지를 처리하기 위한 전자 장치 및 그의 동작 방법
WO2022225195A1 (ko) 무선 네트워크에서 장치 프로비져닝을 위한 전자 장치 및 그 동작 방법
WO2022203174A1 (ko) 네트워크 관리 동작을 수행하는 전자 장치 및 그 동작 방법
WO2022191401A1 (ko) 텍스트 메시지를 이용하여 컨퍼런스 콜의 초대를 수행하는 전자 장치 및 그 제어 방법
WO2022169233A1 (ko) 네트워크 구성 정보를 송수신하는 전자 장치 및 그 동작 방법
WO2022186562A1 (ko) 전자 장치 및 전자 장치에서 아이엠에스 기반의 콜을 처리하는 방법
WO2023163332A1 (ko) 다른 전자 장치와의 통신을 통한 셋업을 실행하기 위한 전자 장치, 방법, 및 비일시적 컴퓨터 판독가능 저장 매체
WO2022225348A1 (ko) 전자 장치 및 전자 장치에서 임베디드 구독자 식별 모듈의 프로파일을 설치하는 방법
WO2022220436A1 (ko) 네트워크 억세스 동작을 수행하는 전자 장치 및 그 동작 방법
WO2022255671A1 (ko) 외부 전자 장치와 통신 연결을 수행하기 위한 전자 장치 및 그의 동작 방법

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: 23799526

Country of ref document: EP

Kind code of ref document: A1