KR101721852B1 - 상태 추적 시스템 - Google Patents

Abstract

거래에 대한 상태 업데이트를 제공하기 위한 시스템들 및 방법들이 본 명세서에 설명된다. 본 발명 주제에 따라서, 거래의 업데이트된 상태 제공하기 위해 시스템(들)은 설명된 방법(들)을 구현한다. 방법은 사용자와 다른 당사자 사이의 거래의 상태를 추적하기 위해 사용자의 통신 디바이스로부터 서버에 의한 상태 업데이트 요청을 수신하는 단계를 포함하고, 여기서 상태 업데이트 요청은 적어도 상태 업데이트와 연관된 추적 파라미터들과 업데이트 파라미터들을 포함한다. 방법은 또한 거래의 업데이트된 상태를 얻기 위해 추적 파라미터들 및 업데이트 파라미터들을 기초로 하여 통신 네트워크를 통해 다른 당사자를 폴링하는 단계를 포함한다. 게다가, 방법은 업데이트 파라미터들을 기초로 하여 거래의 업데이트된 상태를 사용자에게 제공하는 단계를 포함한다.

Description

상태 추적 시스템{STATUS TRACKING SYSTEM}

본 발명은 컴퓨팅 시스템들에 관한 것이며, 특히, 통신 네트워크에서의 컴퓨팅 시스템들에 관한 것이지만 그에 제한되는 것은 아니다.

셀룰러 폰들, 스마트폰들, 개인 휴대 정보 단말기들(PDAs), 태블릿 컴퓨터들, 랩톱 컴퓨터들 및 데스크톱 컴퓨터들과 같은 컴퓨팅 디바이스들은 사용자들에게 다양한 어플리케이션들, 서비스들 및 네트워킹 기능들을 제공한다. 이러한 컴퓨팅 디바이스들은 겉보기에는 오늘날의 라이프 스타일의 유비쿼터스한 부분이 되었고 디지털 기술은 인간 삶과 전문적인 것은 물론 개인적인 다양한 측면들로 개척되어 왔다.

이러한 디지털 시대에서, 기업들과 개인들은 그들이 그들의 고객들, 공급 업체들, 유통 업체들 및 에이전트들과 전통적인 채널들을 통해서 보다는 컴퓨팅 디바이스들과 같은 디지털 수단들을 통해 신속하고 효율적으로 통신할 수 있고 거래할 수 있다는 것을 알고 있다. 개인들은 전화 통화로 식당 예약들을 할 수 있고, 환자들은 웹 서비스들을 통해 진료 예약들을 할 수 있고, 바쁜 사람들은 온라인으로 상품들을 구입할 수 있다. 그러므로, 사람들은 판매들, 구입들, 경매들 기부들, 예약들, 취소들 및 다양한 다른 유사한 거래들과 같은 거래들을 컴퓨팅 시스템들을 통해 누리고 있으며, 이러한 거래들은 점점 더 대중화될 것이다.

보통은 거래들을 처리하는 개인들은 거래에 특정한 레퍼런스 번호를 제공받는다. 거래의 세부사항들을 고유하게 식별하고 검색하기 위해서, 개인들은 이러한 레퍼런스 번호들에 근거하여 그들의 거래를 차후에 문의할 수 있다. 어떤 산업들과 운용방식들에 있어서 개인에 의해 처리된 거래가 실행 시간에 완료되지 않는 것이 또한 일반적이다. 예를 들어, 기차 티켓을 예약하려는 개인은 시간의 적절할 때에 확인될 수 있는 예약 대기 목록을 받을 수 있다. 일반적으로, 이러한 예약 거래에 대해서, 개인들은 개인들이 상태 문의들을 할 수 있는 것을 활용하는 레퍼런스 번호로서의 역할을 하는 여객 이름 기록(PNR:Passenger Name Record)을 제공받는다. 유사하게, 개인들은 주문의 완료 후에 의도된 주소로 배달되는 데에 2-3일이 소요될 수 있는 온라인 포털로부터 상품을 구입할 수 있다. 이러한 상황들에서 또한, 개인들은 배달 상태가 개인들에 의해 추적될 수 있는 것을 기초로 한, 거래 및 추적 번호를 일반적으로 제공받는다. 그러므로, 임의의 거래에 대해 레퍼런스 번호를 제공받은 고객들은 그들의 거래의 진행과정(progress)을 추적할 수 있다.

일반적으로, 임의의 거래의 진행과정 또는 상태에 대한 추적은 다른 당사자에게 개인적으로, 전화로 또는 팩스 문의로 성취된다. 그러나, 통신의 디지털화 및 이미 이용가능한 모드들의 상태로, 이러한 거래들의 진행과정 또는 상태에 대한 추적은 또한 온라인 문의들의 수단으로 실행될 수 있다.

하기의 설명은 거래의 상태를 추적하는 것과 관련된 개념들을 소개하기 위해 제공된다. 이러한 설명은 청구된 본 발명의 청구 대상들을 식별하도록 의도되지 않고 또한 청구된 본 발명의 청구 대상을 결정하거나 제한하는 것으로 의도되지 않았다.

일 실시예에 따르면, 거래의 업데이트된 상태를 사용자에게 제공하기 위한 방법이 설명된다. 이러한 방법은 사용자와 다른 당사자(party) 사이의 거래의 상태를 추적하기 위해 사용자의 통신 디바이스로부터 서버에 의한 상태 업데이트 요청을 수신하는 단계를 포함하고, 상태 업데이트 요청은 상태 업데이트와 연관된 추적 파라미터들(tracking parameters) 및 업데이트 파라미터들 중 적어도 하나를 포함하고, 업데이트 파라미터들은 사용자의 선호도들을 규정한다. 거래의 업데이트된 상태를 얻기 위해, 상기 방법은 또한 추적 파라미터들 및 업데이트 파라미터들을 기초로 하여, 통신 네트워크를 통하여 다른 당사자를 폴링(poll)하는 단계를 포함한다. 게다가, 상기 방법은 업데이트 파라미터들을 기초로 하여, 거래의 업데이트된 상태를 사용자의 통신 디바이스에 제공하는 단계를 포함한다.

또 다른 실시예에서, 거래의 업데이트된 상태를 사용자에게 제공하기 위한 시스템이 설명된다. 시스템은 프로세서를 포함한다. 시스템은 또한 사용자와 다른 당사자 사이에서의 거래의 상태를 추적하기 위해 프로세서에 커플링되고 사용자로부터 상태 업데이트 요청을 수신하도록 구성된 요청 분석 모듈을 포함하고, 상태 업데이트 요청은 상태 업데이트와 연관된 추적 파라미터들 및 업데이트 파라미터들 중 적어도 하나를 포함한다. 시스템은 또한 거래의 업데이트된 상태를 얻기 위해 프로세서에 커플링되고, 추적 파라미터들 및 사용자 선호도들을 기초로 하여, 다른 당사자를 폴링하도록 구성된 문의 모듈(a querying module)을 포함한다. 추가로, 시스템은 프로세서에 커플링되고, 사용자 선호도들을 기초로 하여, 거래의 업데이트된 상태를 사용자에게 제공하도록 구성된 보고 모듈(a reporting module)을 포함한다.

일 실시예에서 거래에 대한 상태 업데이트를 제공하기 위한 방법을 실행하기 위해 이후 실시된 컴퓨터 프로그램을 가진 컴퓨터 판독가능한 매체가 설명된다. 상기 방법은 사용자와 다른 당사자 사이의 거래의 상태를 추적하기 위해 사용자로부터 상태 업데이트 요청을 수신하는 단계를 포함하고, 상태 업데이트 요청은 상태 업데이트와 연관된 추적 파라미터들 및 업데이트 파라미터들 중 적어도 하나를 포함한다. 상기 방법은 또한 거래의 업데이트된 상태를 얻기 위해, 추적 파라미터들 및 사용자 선호도들을 기초로 하여 다른 일행을 폴링하는 단계를 포함한다. 게다가, 상기 방법은 사용자 선호도들을 기초로 하여 거래의 업데이트된 상태를 사용자에게 제공하는 단계를 포함한다.

상세한 설명은 첨부된 도면들을 참조하여 설명된다. 도면들에서, 참조 번호의 가장 왼쪽의 자리 숫자(들)는 참조 번호가 처음으로 나타난 도면과 동일하다. 동일한 번호들이 같은 특징들 및 구성요소들을 참조하기 위해 도면들 전체에 걸쳐 사용된다. 본 발명 주제의 실시예들에 따른 시스템 및/또는 방법들의 일부 실시예들이 첨부된 도면들을 참조하여 오직 예로서 이제 설명된다:

도 1은 본 발명 주제의 실시예에 따른 상태 추적을 위한 시스템을 실시하는 통신 네트워크 환경을 도시한 도면.
도 2는 본 발명 주제의 실시예에 따른 거래의 업데이트된 상태를 사용자에게 제공하기 위한 방법을 도시한 도면.

본 명세서에 임의의 블록 다이어그램들이 본 발명 주제의 원리들을 구현하는 도시적인 시스템들의 개념도들을 나타낸다는 것이 당업자들에 의해 이해되어야 한다. 유사하게, 임의의 플로우 챠트들, 플로우 다이어그램들, 상태 거래 다이어그램들, 모조 코드(pseude code) 등이 컴퓨터 판독가능한 매체에 대체로 해당될 수 있고 그래서 컴퓨터 또는 프로세서에 의해 실행될 수 있는 다양한 과정들을 나타낸다는 것이 이해될 것이고, 어떻든지 간에 이러한 컴퓨터 또는 프로세서가 명시적으로 도시된다.

거래의 상태를 추적하기 위한 시스템들 및 방법들이 본 명세서에 설명된다. 상기 방법들은 다양한 네트워크들을 통해 통신하는 다양한 컴퓨팅 디바이스들에서 실시될 수 있다. 비록 본 명세서의 설명은 통신 네트워크의 시스템들을 참조하기는 하지만, 방법들 및 시스템들은 약간의 변형들이 있을지라도 당업자에 의해 이해될 것이므로, 거래들의 상태를 제공할 수 있는 다른 시스템들에서 실시될 수 있다.

도시들의 바쁜 생활에서, 다수의 거래들이 하루 동안 이루어진다. 많은 조직들은 상품들을 구입하고 배달한다; 다수의 사용자들은 그들의 필요의 항목들을 구입한다; 사람들은 병원들, 호텔들, 클리닉들 등과 같은 다양한 기관들에서 예약을 한다; 여객들은 한 장소에서 또 다른 장소로의 여행을 위한 티켓들을 예약한다. 몇몇의 거래들은 현장에서 또는 개시 이후 짧은 시간의 기간에 완료된다. 그러나, 완료 하는 데에 일정 시간이 걸리는 많은 거래들이 존재한다. 예를 들어, 개인이 좌석들을 이용할 수 없기 때문에 확인될 수 없는, 미국에서 부탄으로의 그의 여행에 대한 비행기 티켓을 예약하려고 시도할 수 있다. 이러한 상황에서, 항공사는 개인에게 티켓을 거절하는 것을 결정할 수 있거나, 취소가 있을 경우에, 확정될 수 있는 대기 목록 티켓을 그에게 제공할 수 있다. 유사하게, 택배 배달 및 온라인 쇼핑과 같은 다른 거래들은, 상품의 운송 및 배달이 몇 일 심지어 몇 주의 기간으로 연장될 수 있기 때문에, 전체적으로 완료하는 데 시간이 걸릴 수 있다.

거래들이 즉시 완료되지 않는 경우들에서, 개인들은 거래의 상태를 추적할 필요성을 느낀다. 거래의 업데이트된 상태는 사용자들로 하여금 그들의 차후 활동들을 계획할 수 있도록 해주고, 또한 거래의 의도된 진행과정의 확인을 제공할 수 있다. 예를 들어, 한 승객의 대기 목록 번호에서의 어떠한 감소는 그가 그의 여행을 계획할 수 있도록 할 수 있는 예약 확정(confirmation)의 향상된 가능성의 표시를 그에게 제공할 수 있다. 유사하게, 수송 세부사항들에서의 업데이트는 사용자로 하여금 수송의 배달에 대해 남은 시간 기간을 예측할 수 있게 한다.

전통적으로, 회사들 및 개인들은 거래를 위해 제공받은 레퍼런스 번호에 기초하여 다른 관련 당사자(party)로부터 임의의 거래에 대한 상태의 개인 문의(enquiry)의 방법들에 의존한다. 사람들은 다른 당사자(party)의 사무실 건물들을 방문하거나 다른 당사자(party)의 승인된 카운터로부터 거래의 상태를 얻는다. 개인적인 문의가 가능하지 않은 상황들에서, 전화 서비스들 및 팩시밀리(fax) 서비스들이 사용된다. 거래들이 완료하는 데에 수 일이 걸리는 로지스틱스(logistics) 서비스들과 같은 산업들에서, 상태 추적은 가장 중요하고, 로지스틱스 지원을 제공하는 서비스 회사들은 또한 상태 업데이트들을 고객들에게 제공하는 것을 용이하게 하기 위해 전용 전화 번호들, 톨-프리라인들(toll-free lines), 전용 작동자들 및 대화식의 음성 반응 시스템들(IVRS:Interactive Voice Response Systems)을 제공한다.

기술의 성장과 월드 와이드 웹(World Wide Web), 모바일 컴퓨팅 및 통신 디바이스들의 인기 증가로, 새로운 서비스들이 인터넷 상에 등장했다. 모바일 단말기들은 중앙 데이터베이스들에 접속할 수 있고, 필요로 될 때 및 필요로 되는 곳이라면 어디든지 정보를 사용자들에게 전달할 수 있다. 회사들 및 서비스 제공자들은 또한 기술의 힘을 활용하여 웹 포털들, 어플리케이션들 및 웹 서비스들을 제공하고, 이를 통해 사용자들은 그들의 거래들의 상태를 추적할 수 있다. 예를 들어, 거래에 따라 제공받은 레퍼런스 번호를 기초로 하여, 고객들은 거래의 업데이트된 상태를 얻기 위해 서비스 제공 당사자의 데이터베이스를 문의할 수 있다(query). 이러한 모든 서비스들의 가용성이 고객들로 하여금 그들의 거래들의 상태를 추적하는 것을 훨씬 더 쉽게 하기는 하지만, 고객들은 상태 업데이트를 얻기 위해 이러한 서비스들을 통해 질문 요청을 여전히 개시해야 한다.

최근에, 서비스 제공자들은 고객들에 의한 명시적인 개시 없이, 거래의 상태 업데이트를 자동으로 고객들에게 제공될 수 있는 방법을 채택했다. 고객들은 전화 통화들 단문 메시지 서비스(SMS:Short Message Service), 이메일들 또는 알림들 중 하나를 통해, 그들의 거래의 상태에 대해 알게 된다. 일반적으로 이러한 자동화된 상태 업데이트들은 주기를 기초로 하여, 또는 거래의 상태 변화가 있게 됨에 따라 또는 그러한 때 제공된다. 예를 들어, 승객에게 대기 목록 티켓을 제공했던 항공사는 티켓이 확인될 때까지 사용자에게 예약의 상태를 제공할 수 있고, 또는 그것이 변할 때 티켓 예약 상태의 업데이트를 제공할 수 있다.

그러나, 상술된 기술들에서, 사용자에게 제공된 상태 업데이트는 사용자들에게 어떠한 선택이나 조절 권한도 제공하지 않고 다른 당사자에 의해 명령된다. 자동 업데이트들은 사용자 선택들 또는 사용자의 선호도들을 고려하지 않는 다른 당사자의 정책을 기초로 제공된다. 예를 들어, 오직 거래의 상태에서의 변화에 따른 업데이트만을 원할 수 있는 고객들에 대해서, 상태의 매일 또는 매 시간 업데이트는 자원의 낭비가 될 수 있고, 또한 고객에게 스팸으로서 행동할 수 있다. 유사하게, 또 다른 고객은 제공된 업데이트들이 매일 이루어질 수 있는 매 시간 업데이트를 수신하기를 원할 수 있다. 이러한 시나리오에서, 매 시간 업데이트된 상태를 얻기 위해, 고객은 웹 문의, 전화 문의 또는 팩스 문의와 같은 다른 방법들을 개시해야 할 수 있다. 그러므로, 업데이트된 상태 정보로의 액세스를 원하는 사용자들을 위해, 현재 이용 가능한 기술들은 셀프 개시로의 액세스를 제한하거나 또는 다른 당사자들에 의해 활동된 선택에 기초하여 자동화된 상태 업데이트들에 의존한다.

본 발명 주제의 일 실시예에 따라서, 사용자 선호도들을 기초로 한 상태 추적에 대한 방법들이 본 명세서에 설명된다. 한 편 으로, 설명된 방법들은 거래의 상태를 추적하는 것의 효율적인 방법을 허용한다; 다른 한편으로, 원치 않는 것을 제거하는 메커니즘들과 최후의 상태 업데이트들을 제공한다. 본 발명 주제의 설명된 실시예에 따라서, 상태 업데이트는 비행기 예약, 기차 예약, 버스 예약, 시네마 티켓 예약, 로지스틱 거래들, 진료 예약들 및 구입/배달 보고들과 같은 상이한 거래들에 대해서 사용자에게 제공될 수 있다. 명세서가 예약 시스템들에 관하여 설명되기는 하였지만, 당업자에 의해 이해될 수 있는 바와 같이, 설명된 방법은 약간의 변형들이 있을지라도, 거래들의 다른 타입에 대해서 또한 실행될 수 있다.

더욱이, 거래들의 상태는 상이한 기능들을 핸들링/활용하는 메일 서버들, 중앙 디렉터리 서버들, 데이터베이스 서버들, 파일 서버들, 프린트 서버들, 웹 서버들, 어플리케이션 서버들, 노트북들, 태블릿 컴퓨터들, 네트워크 액세스 어댑터들 등과 같은 상이한 컴퓨팅 디바이스들, 서버들 및 사용자들을 통해 추적될 수 있다.

본 발명 주제의 일 실시예에서, 통신 네트워크 연결성을 사용자에게 제공하는 서비스 제공자는 상태 업데이트들을 사용자에게 제공하는 서비스를 제공할 수 있다. 통신 네트워크 또는 무선 액세스 네트워크(RAN)로의 접속성을 얻기 위해, 사용자들은 일반적으로 다양한 서비스들이 이용가능하게 될 수 있는 것을 통해, 서비스 제공자에 가입한다(subscribe)는 것이 당업자에 의해 이해될 것이다. 예를 들어, 한 사용자가 3G 서비스들에 유익한(availing) 서비스 제공자 'A'에 가입(subscribe)할 수 있다. 유사하게, 또 다른 사용자는 통신 네트워크와 인터넷 프로토콜 TV(IPTV)를 통한 인터넷으로의 접속성을 얻기 위해 서비스 제공자 'B'에 가입할 수 있다. 상기 실시예에서, 서비스 제공자는 상태 추적 서비스들을 제공하기 위해 사용자들로부터 요청들을 수신할 수 있다. 서비스 제공자가 그들의 통신 디바이스들을 통해 다른 사용자들과 통신하기 위해, 통신 네트워크와의 접속성을 사용자에게 제공한다는 것이 당업자에 의해 이해될 것이다.

또 다른 실시예에서, 사용자 선호도들을 기초로 상태 업데이트들을 사용자에게 제공하는 서비스는 사용자 또는 다른 당사자 보다도 제 3자에 의해 제공될 수 있다. 이러한 실시예에서, 제 3자는 사용자의 각각의 서비스 제공자를 통해 사용자 선호도들을 수신할 수 있고, 사용자에 의해 요청된 모드를 통해 업데이트된 상태를 제공할 수 있다. 제 3자가 사용자가 가입하지 않았던 그리고 상태 업데이트들의 서비스를 제공하는 또 다른 서비스 제공자가 또한 될 수 있다는 것이 이해될 것이다.

일 실시예에서, 서비스 제공자는 사용자로부터 상태 업데이트 요청을 수신할 수 있다. 상태 업데이트 요청은 사용자가 업데이트들을 수신하기를 원하는 거래의 추적 파라미터들을 나타낼 수 있다. 예를 들어, 기차 예약의 상태를 추적하기를 원할 수 있는 사용자에 대한 접속성을 제공하는 서비스 제공자는 사용자로부터 상태 업데이트 요청을 수신할 수 있다. 상태 업데이트 요청은 사용자와 철도 시스템 사이의 거래의 세부사항들과 같은 추적 파라미터들을 포함할 수 있다. 추가로, 요청은 또한 사용자와 철도 시스템 사이의 예약의 거래와 연관된 레퍼런스 번호를 포함할 수 있다.

상술된 시나리오에서, 사용자가 인도 철도로 기차 티켓을 예매했던 경우, 인도 철도 캐터링 관광 공사(IRCTC:Indian Rail Catering and Tourism Corporation)를 통한 인도 철도는 사용자에게 취소에 대한 예약(RAC:Reservation Against Cancellation) 예약을 제공했을 수 있다. 이미 확인된 예약들을 가진 승객들이 그들의 티켓들을 취소하기로 결정하고, 그것으로 그 여행에 대해 공석이 개방되는 상황들에서, RAC 예약이 확인될 수 있다는 것이 이해될 것이다. 사용자에게 제공된 예약은 임의의 취소의 대상이기 때문에, 사용자는 예약의 상태에 대한 업데이트를 주기적으로, 말하자면, 매 12시간 후에, 얻기를 원할 수 있다. 이러한 시나리오에서, IRCTC는 기차 번호, 기차 이름, 출발 역 이름, 도착 역 이름, PNR 및 예약에 대해 부과된 요금을 포함한 예약 세부사항들을 포함할 수 있는 경우, 거래 세부사항들을 사용자에게 제공할 수 있다. IRCTC에 의해 제공된 바와 같은 이러한 세부사항들을 가진 예약에 대해, 사용자는 그의 거래의 상태를 확인하기 위해 서비스 제공자로부터 현재 상태를 얻는 것을 결정할 수 있다. 사용자는 예약의 거래에 대한 참조를 고유하게 제공하기 위해 상태 업데이트 요청을 서비스 제공자에게 추적 파라미터들과 같은 거래 세부사항들에 따라서 전송할 수 있다.

거래와 연관된 전체 상세 세트가 임의의 거래에 대한 참조의 목적을 위해 사용자에 의해 서비스 제공자에게 제공되지 않을 수 있다는 것이 이해될 것이다; 데이터베이스들은 일반적으로 유사한(corresponding) 기록을 고유하게 식별하기 위해 주요한 키로서 단일 엔티티를 규정한다. 예를 들어, 상술된 시나리오에서, 예약에 대해 사용자에게 제공된 PNR은 IRCTC로 하여금 사용자에 의해 이루어진 예약의 세부사항들을 고유하게 식별하도록 할 수 있다. 그러므로, 사용자는 거래의 PNR에 따라서 상태 업데이트 요청을 제공할 수 있다.

일 실시예에서, 사용자는 또한 상태 추적의 목적을 위해 서비스 제공자에게 다른 당사자 세부사항들을 제공할 수 있다. 다른 당사자는 사용자가 거래를 함께했던 당사자로서 이해될 것이다. 예를 들어, 기차 예약의 상술된 예시에서, 다른 당사자는 IRCTC가 될 것이다. 그러므로, 레퍼런스 번호와 같은 세부사항들을 포함할 수 있는 거래 세부사항들에 따라서, 상태 업데이트 요청은 또한 다른 당사자의 세부사항들을 포함할 수 있다. 즉, 사용자가 RAC 예약을 제공받은 상술된 시나리오에서, 사용자는 또한 'IRCTC' 이름 또는 IRCTC 웹 문의 유니폼 리소스 로케이터(URL:Uniform Resource Locator)와 같은 다른 당사자 세부사항들을 거래 세부사항들에 따른 상태 업데이트 요청에서 제공할 수 있다. 다른 당사자 세부사항들은 상태 업데이트를 사용자에게 제공하기 위해 서비스 제공자로 하여금 제공된 다른 당사자에 대해서 거래 세부사항들을 고유하게 대응하도록 할 수 있다.

사용자가 다른 당사자의 세부사항들을 제공할 수 있는 것이 설명되었기는 하지만, 그러나, 일 실시예에서, 서비스 제공자는 상태 업데이트의 서비스가 사용자에게 제공될 수 있는 것을 위해 다른 당사자들의 목록을 제공할 수 있다. 옵션들의 제공된 목록으로부터, 사용자는 사용자가 거래를 함께 완료했던 다른 당사자를 선택할 수 있다. 서비스 제공자는 그들의 거래들의 상태를 추적하는 서비스를 제공할 수 있는 상인들, 공급자들, 의학적 소스들, 예약 포털들 및 다른 당사자들과 같은 다른 당사자들의 총망라한(exhaustive) 목록을 제공할 수 있다.

본 발명 주제의 또 다른 실시예에서, 서비스 제공자는 상태 업데이트 요청에 대한 업데이트 파라미터들을 규정하는 것의 옵션들을 사용자에게 제공할 수 있다. 업데이트 파라미터들은 상태 업데이트 요청과 연관된 사용자 선호도들을 규정할 수 있다. 상기 실시예에서, 업데이트 파라미터들은 업데이트 빈도, 업데이트 기간, 업데이트 모드 및 업데이트의 시간을 포함할 수 있지만, 이에 제한되는 것은 아니다. 업데이트 파라미터의 빈도는 거래의 상태 업데이트가 사용자에 의해 원해진 빈도로 규정할 수 있다. 다시 말하면, 그들의 필요조건들을 기초로 한 사용자들은 그들의 거래의 상태에 대해 자동 업데이트들을 수신하기를 원한 후에 시간 기간을 규정할 수 있다. 예를 들어, RAC 예약을 가진 사용자는 그가 그의 예약상태의 자동 업데이트들을 수신하기를 원할 수 있는 후에 4 시간의 빈도를 규정할 수 있다.

유사하게, 사용자는 또한 그가 거래의 상태에 대한 업데이트들을 수신하기를 원할 수 있는 기간을 선택하고 규정할 수 있다. 즉, 사용자는, 또 다른 사용자가 1일 동안 3시간의 빈도로 업데이트들을 수신하기를 원할 수 있는 반면에, 거래에 대해 3일 동안 매 2시간 후에 상태 업데이트들을 수신하기를 원할 수 있다. 그러므로, 그들의 선호도들을 기초로, 업데이트 파라미터의 기간 파라미터를 규정하여 상태 업데이트들을 수신할 수 있다. 상기 실시예에서, 사용자는 또한 마일스톤(milestorne) 기반 업데이트들(즉, 상태는 상태가 미리-결정된 마일스톤으로 변할 때만 업데이트 된다)을 선택할 수 있다. 예를 들어, 사용자가 IRCTC를 통해 RAC 예약을 제공받는 상술된 예시에서, 사용자는 예약의 상태가 'RAC' 에서 '확인된 예약'(confirmed reservation)으로 변할 때, 마일스톤으로서 업데이트에 대한 기간을 규정할 수 있다. 이러한 시나리오에서, 서비스 제공자는 예약 상태가 확인된 것으로 변할 때, 완료하는 기간을 다이내믹하게 결정할 수 있다. 다시 말하면, 상태 업데이트는 예약이 RAC 예약인 순간까지만 제공될 수 있고 확인하자마자 종료될 수 있다.

이제 또 다른 실시예에서, 사용자는, 특정 시간 제한 또는 구체적인 마일스톤을 결정하는 것보다 거래의 완료를 하자마자 상태 업데이트 요청들을 자동적으로 종료하는 것을 선택할 수 있다. 상이한 거래들이 상이한 방식들 예를 들어, 여행 예약은 여정이 완료되자마자 완료할 수 있는 방식으로 완료할 수 있다는 것이 이해될 것이다. 식당 예약은 식사가 완료되자마자 이루어질 수 있고, 약속은 회의가 완료되자 마자 이루어 질 수 있고, 기타 등등이 있다. 그러므로, 서비스 제공자는 사용자에게 업데이트들을 자동적으로 종료하기 위해, 거래 세부사항들 및 다른 당사자 세부사항들을 기초로, 거래의 완료를 확인할 수 있다.

더욱이, 업데이트 파라미터들은 또한 서비스 제공자가 상태 업데이트를 사용자에게 제공할 수 있는 것을 기초로, 업데이트의 모드를 포함할 수 있다. 사용자는 SMS, IVRS 호, 이메일, 전화 통화, USSD 응답 및 다른 것들을 포함할 수 있으나 이에 제한되는 것은 아닌 다양하고 상이한 옵션들을 선택할 수 있다. 예를 들어, 사용자는 업데이트 파라미터의 모드를 IVRS 호가 되도록 선택할 수 있다. 이러한 상황에서, 서비스 제공자는 거래의 상태를 제공하는 IVRS 호를 통해서 거래의 업데이트된 상태를 사용자에게 제공할 수 있다.

본 발명 주제의 일 실시예에서, 상태 업데이트 요청은 사용자로부터 데이터/정보를 수신하는 다수의 인터페이스들 및 기술들을 통해 서비스 제공자에 의해 수신될 수 있다. 상기 실시예에서, 서비스 제공자는 무선 액세스 네트워크(RAN)에서 비구조형 부가서비스 데이터(USSD:Unstructured Supplementary Service Data) 메시지를 통해 상태 업데이트 요청을 수신할 수 있다. 또 다른 실시예에서, 사용자는 거래 세부사항들 및 다른 당사자 세부사항들에 따른, 상태 업데이트 요청을 SMS를 통해 제공할 수 있다. 유사하게, 상태 업데이트 요청은 상이한 기술들을 통해 사용자로부터 수신될 수 있다. 상태 업데이트 요청이 RAN을 통해 서비스 제공자에 의해 수신될 수 있는 것이 설명되기는 하였지만, 요청이 또한, 텔레비전을 위한 케이블 연결들; 고정된 전화 선로 재래식 전화 시스템(POTS:plain old telephone system) 네트워크들과 같은 두 개의 와이어 회로들(로컬 루프들); 케이블 방송 네트워크들; 종합 정보 통신망(ISDN:Integrated Services Digital Network); 공중 교환 전화 네트워크들(PSTN:Public Switched Telephone Networks) 및 이메일, 경계정보(alerts), IPTV, IVRS 및 SMS 같은 서비스들을 포함하는 디지털 가입자 회선(DSL:Digital Subscriber Line) 네트워크들의 다른 변형들을 포함하나 이에 제한되는 것은 아닌 다른 수단들을 통해 수신될 수 있다는 것이 이해될 것이다.

본 발명 주제의 일 실시예에서, 서비스 제공자는 상태 업데이트 요청을 수신하자 마자, 요청에 대한 고유의 레퍼런스 번호(URN:Unique Reference Number)를 생성하고 이것을 사용자에게 제공한다. URN은 서비스 제공자와 사용자가 URN을 기초로 그것과 연관된 상태 업데이트 요청 및 세부사항들을 고유하게 결정할 수 있는 거래의 레퍼런스 번호와 유사하다는 것이 이해될 수 있다.

그러므로, 거래의 세부사항들, 다른 당사자 세부사항들 및 업데이트 파라미터들을 기초로 하여ㄱ, 서비스 제공자는 업데이트된 거래들의 상태를 확인하기 위해 상이한 사용자들로부터 수신된 각 URN의 상태를 결정할 수 있다. URN에 대해, 서비스 제공자는 거래의 업데이트된 상태를 수신하기 위해 연관된 다른 당사자를 폴링(poll)할 수 있다. 업데이트된 상태가 사용자에 의해 선택된 기간과 빈도를 기초로 하여 서비스 제공자에 의해 결정될 수 있다는 것이 이해될 것이다. 다시 말해서, 2 시간의 빈도를 가진 사용자에 대해, 폴링은 매 2시간마다 발생할 것이며, 반면에 사용자가 1일의 빈도로 설명했을 상황에서는, 거래의 폴링은 하루에 한번 발생할 것이다.

거래에 대해 업데이트된 상태를 얻기 위한 폴링은 사용자에 의해 제공된 다른 당사자 세부사항들을 기초로 될 수 있다. 다른 당사자 세부사항들은 거래의 업데이트된 상태를 얻기 위해 서비스 제공자로 하여금 다른 당사자의 문의 서비스로의 액세스를 얻도록 할 수 있는 URLs, IVRS 번호들 및 다른 세부사항들을 규정할 수 있다. 상태가 거래에 대해 변하지 않을 수 있기 때문에, 수행되는 모든 폴링이 거래에 대한 새로운 상태를 제공하지 않을 수 있고, 그러므로, 거래의 상태에 변화가 없는 상황들에서, 동일한 상태가 서비스 제공자에 의해 사용자에게 제공될 수 있다는 것이 이해될 것이다.

일 실시예에서, 서비스 제공자에 의해 수신된 업데이트된 상태는 사용자에 의해 원해진(desired) 모드들 중 하나를 통해 사용자에게 제공된다. 상술된 바와 같이, 업데이트는 이메일, SMS, USSD 메시지, IVRS 호 및 다른 암시 방법들(intimation methods)을 통해 제공될 수 있다. 상기 실시예에서, 서비스 제공자는 또한 사용자에게 그의 선호도들을 기초로 상태 업데이트를 제공하는 서비스에 대해 요금을 부과할 수 있다. 추가로, 과금 방안(charging mechanism)은 예를 들어 매 2시간 마다의 업데이트들을 원하는 사용자는 매 6시간 마다의 업데이트들을 원하는 사용자 보다 더 많은 요금이 부과될 수 있는 등 사용자의 특정한 선호도들을 기초로 가지각색일 수 있다.

상술된 기술들을 기초로 하여, 사용자는 사용자 선호도들을 기반으로 거래에 대해 자동 업데이트된 상태를 제공받을 수 있다. 사용자는 업데이트가 원해지는 모든 순간에 대한 새로운 조회 요청을 증명하지 않을 수 있고, 대신에 서비스 제공자에 대해 한 번 상태 업데이트 요청은 업데이트된 상태를 사용자에게 제공할 수 있다. 추가로, 사용자는 또한 그들의 선호도를 기초로 업데이트들의 보고를 선택하도록 허용되어 그것으로 다른 당사자들에 대한 임의의 의존물(dependency)을 제거한다.

설명된 방법들은 하드웨어, 펌웨어, 소프트웨어 또는 이들의 조합으로 실시될 수 있다. 하드웨어 구현에 대해, 프로세싱 유닛들은 하나 이상의 응용 주문형 집적 회로(ASICs:application specific integrated circuits), 디지털 신호 처리기들(DSPs:digital signal processors), 디지털 신호 프로세싱 디바이스들(DSPDs:digital signal processing devices), 프로그래머플 로직 디바이스들(PLDs:programmable logic devices), 필드 프로그래머블 게이트 배열들(FPGAs:field programmable gate arrays), 프로세서들, 제어기들, 마이크로-제어기들, 마이크로프로세서들, 전자 디바이스들, 본 명세서에 설명된 기능들을 수행하도록 설계된 다른 전자 유닛들 또는 이들의 조합 내에서 구현될 수 있다. 본 명세서에서, 용어 "시스템"은 소프트웨어, 하드웨어, 펌웨어 또는 이들의 조합에 의해 구현된 로직을 포함한다.

펌웨어 및/또는 소프트웨어 구현 환경에 대해, 방법들은 메모리에 저장된 모듈들(예를 들어, 절차들, 기능들 등)로 구현될 수 있고, 소프트웨어 명령어들은 본 명세서에 설명되는 방법(들)을 구현하기 위해 프로세서에 의해 실행된다. 명령어들을 명백히 구체화하는 임의의 컴퓨터 판독가능한 매체가 본 명세서에 설명된 방법들을 구현하는 데에 사용될 수 있다. 예를 들어, 소프트웨어 코드들 및 프로그램들은 컴퓨터 판독가능한 메모리에 저장될 수 있고 본 명세서에 설명된 방법을 실시하기 위해 프로세싱 유닛에 의해 실행된다. 메모리는 프로세싱 유닛 내에서 구현될 수 있거나 프로세싱 유닛에 대해 외부일 수 있다. 본 명세서에서 사용된 용어 "메모리"가 긴 용어, 짧은 용어, 휘발성, 비휘발성 또는 다른 저장 디바이스들의 임의의 타입을 나타내기 때문에, 메모리의 임의의 특정 타입 또는 메모리들의 번호, 또는 메모리가 저장된 미디어(media upon)의 타입에 제한되지 않는다.

또 다른 펌웨어 및/또는 소프트웨어 구현에서, 기능들은 비 일시적인 컴퓨터-판독가능한 매체 상에 하나 이상의 명령어들 또는 코드로서 저장될 수 있다. 예시들은 데이터 구조로 인코딩된(encode) 컴퓨터-판독가능한 매체 및 컴퓨터 프로그램으로 인코딩된 컴퓨터-판독가능한 매체를 포함한다. 컴퓨터-판독가능한 매체는 제조자의 물품의 형태를 취할 수 있다. 컴퓨터-판독가능한 매체는 물리적 컴퓨터 저장 매체를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 이용가능한 매체가 될 수 있다. 예로서, 이러한 컴퓨터-판독가능한 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 저장, 자기 디스크 저장 또는 다른 자기 저장 디바이스들 또는 명령어들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 저장하기 위해 사용될 수 있고 컴퓨터에 의해 액세스 될 수 있는 임의의 다른 매체를 포함할 수 있으나 이에 제한되는 것은 아니고; 본 명세서에서 사용된 디스크(disk) 및 디스크(disc)는 컴팩트 디스크(CD), 레이저 디스크, 광 디스크, 디지털 다기능 디스크(DVD:digital versatile disc), 플로피 디스크 및 블루레이 디스크(Blu-ray disc)를 포함하고, 디스크들(discs)이 데이터를 레이저들과 광학적으로(optically) 재생하는 반면, 디스크들(disks)은 보통 데이터를 자기로(magnetically) 재생한다. 위의 조합들은 또한 컴퓨터-판독가능한 매체의 범위 내에서 포함되어야 한다.

명세서가 단지 본 발명 주제의 원리들을 도시하고 있다는 것을 유의해야 한다. 그러므로, 비록 본 명세서에 명백히 설명되지 않았지만, 당업자들이 본 발명 주제의 원리들을 구체화하고 이것의 사상 및 범위 내에 포함된 다양한 배열들을 고안할 수 있다는 것이 이해될 것이다. 더욱이, 본 명세서에 인용된 모든 예시들은 주로 독자들이 본 발명의 원리들 및 분야에 추가하여(to furthering the art) 발명자(들)에 의해 기여된 개념들을 이해하는 것을 돕기 위해 단지 교육적인 목적들을 위한 것으로 명백히 의도되며, 이러한 구체적으로 인용된 예시들 및 조건들에 제한 되지 않는 것으로 해석된다. 게다가, 본 명세서에서 구체적인 예시들 그것으로서의 뿐만 아니라 원리들, 양상들 및 본 발명의 실시예들을 인용하는 모든 문장들은 그것으로서 동등한 것들을 포함하도록 의도된다.

시스템들 및 방법들이 구현될 방식이 도 1 및 도 2에 관하여 상세히 설명되었다. 설명된 시스템들 및 방법들의 양태들이 상이한 컴퓨팅 시스템들, 전송 환경들 및/또는 구성들의 임의의 번호로 구현될 수 있는 반면, 실시예들이 다음의 예시적인 시스템(들)의 문맥에서 설명된다.

본 명세서에서 사용된 동안(during), 반면(while) 및 때(when)와 같은 단어들은 작동이 개시되자마자 즉시 발생하는 작동을 의미하는 정확한 단어들은 아니지만, 개시 작동에 의해 개시되는 개시 작동과 반응 사이에서 전달 지연(propagation delay)과 같은 약간 작을 수 있지만 합리적인 지연이 존재할 수 있다는 것이 당업자에 의해 이해될 것이다. 추가로, 연결된("connected") 및 결합된("coupled") 단어는 설명의 정확성을 위해 전체에 걸쳐 사용되며 직접 연결 또는 간접 연결 중 하나를 포함할 수 있다.

도 1은 본 발명 주제의 일 실시예에 따른 거래에 대한 상태 업데이트를 제공하기 위해 시스템(102)을 구현하는 네트워크 환경(100)을 도시한다. 본 명세서에 설명된 시스템(102)은 라우터들, 브릿지들(bridges), 서버들, 컴퓨팅 디바이스들, 저장 디바이스들 등을 포함한 다양한 네트워크 디바이스들로 이루어진 임의의 네트워크 환경에서 구현될 수 있다. 일 실시예에서, 시스템(102)은 하나 이상의 사용자 디바이스들(104-1,104-2,104-N)로 연결되고 네트워크(106)를 통해 이하에 사용자 디바이스(들)(104)로서 개별적으로 그리고 일반적으로 리퍼링될 수 있다(refer to). 사용자 디바이스들(104)은 상이한 사용자들 및 개별적인 조직들에 의해 요구된 바와 같이, 몇몇의 기능들을 수행하기 위해 운영될 수 있는 다수의 어플리케이션들을 포함할 수 있다.

시스템(102)은 다양한 서버들과 통신 디바이스들로서 구현될 수 있다. 설명된 방법(들)을 구현할 수 있는 통신 디바이스들은 메일 서버, 중앙 디렉토리 서버들, 데이터베이스 서버, 파일 서버, 프린트 서버, 웹 서버, 어플리케이션 서버 등을 포함하지만 이에 제한되는 것은 아니다. 시스템(102)은 또한 랩톱 컴퓨터, 데스크탑 컴퓨터, 노트북, 워크스테이션, 메인프레임 컴퓨터, 서버 등과 같은 컴퓨팅 디바이스로서 구현될 수 있다. 라우터들, 브릿지들, 서버들, 컴퓨팅 디바이스들, 저장 디바이스들 등을 포함한 다양한 네트워크 디바이스들로 이루어진 임의의 네트워크 환경에서, 본 명세서에 설명된 시스템(102)은 또한 무선 네트워크 제어기(RNC:Radio Network Controller), 노드 B, 기지국 제어기(BSC:Base station controller), 모바일 교환 센터(MSC:Mobile Switching Center), 홈 위치 등록기(HLR:Home location Register), 방문 위치 등록기(VLR:Visiting Location Register), 어플리케이션 서버, 미디어 서버 및 서비스 제어 포인트와 같은 네트워크 엔티티로서 구현될 수 있다.

사용자 디바이스들(104)은 데스크탑 컴퓨터들, 손에 쥐고 쓸 수 있는(hand-held) 디바이스들, 랩톱 컴퓨터들 또는 다른 이동가능한 컴퓨터들, 태블릿 컴퓨터들, 모바일 폰들, PDAs, 스마트폰들 등으로서 구현될 수 있으나 이에 제한되는 것은 아니다. 추가로, 사용자 디바이스들(104)은 상이한 통신 디바이스들 및 컴퓨팅 시스템들로의 접속성을 제공하기 위해 데이터를 교환할 수 있는 디바이스들을 포함할 수 있다. 이러한 디바이스들은 데이터 카드들, 모바일 어댑터들, 무선(

) 어댑터들, 라우터들, 무선 모뎀, 무선 통신 디바이스, 코드가 없는 폰 ,무선 로컬 루프(WLL:wireless local loop) 스테이션 등을 포함할 수 있으나 이에 제한되는 것은 아니다. 사용자 디바이스들(104)이 정지될 수 있거나 이동할 수 있을 때, 사용자 디바이스들은 또한 모바일 스테이션, 단말기, 액세스 단말기, 가입자 유닛, 스테이션 등으로서 이해될 수 있다.

네트워크(106)는 무선 또는 유선 네트워크 일 수 있고 또는 이들의 결합일 수 있다. 네트워크(106)는 서로 연결되고 하나의 대형 네트워크(예를 들어, 인터넷 또는 인트라넷)로서 기능하는 개별적인 네트워크들의 집합일 수 있다. 이러한 개별적인 네트워크의 예시들은 모바일 통신에 대한 글로벌 시스템(GSM:Global System for Mobile Communication) 네트워크, 범용 이동 통신 시스템(UMTS:Universal Mobile Telecommunications System) 네트워크, 개인 통신 서비스(PCS:Personal Communications Service) 네트워크, 시간 분할 다중 접속(TDMA:Time Division Multiple Access) 네트워크, 코드 분할 다중 접속(CDMA:Code Division Multiple Access) 네트워크, 차세대 통신 네트워크(NGN:Next Generation Network), 공중 교환 전화 네트워크(PSTN:public switched telephone network) 및 종합 정보 통신 네트워크(ISDN:integrated services digital network)를 포함하지만 이에 제한되는 것은 아니다. 기술에 따라서, 네트워크(106)는 게이트웨이들, 라우터들과 같은 다양한 네트워크 엔티티들을 포함한다; 그러나, 이러한 세부사항들은 이해의 편의를 위해 생략되었다.

일 실시예에서, 시스템(102)은 프로세서(들)(108)을 포함한다. 프로세서(108)는 하나 이상의 마이크로프로세서들, 마이크로컴퓨터들, 마이크로제어기들, 디지털 신호 프로세서들, 중앙 프로세싱 유닛들, 상태 기계들, 로직 회로들 및/또는 연산 명령어들(operational instructions)을 기초로 신호들을 조종하는 임의의 디바이스들로서 구현될 수 있다. 다른 기능들 중에서, 프로세서(들)는 메모리에 저장된 컴퓨터-판독가능한 명령어들을 꺼내고 실행하도록 구성된다.

"프로세서(들)"로 라벨링된 임의의 기능적 블록들을 포함하는 도면에 도시된 다양한 요소들의 기능들은 적합한 소프트웨어와 공동으로(in association with) 소프트웨어를 실행할 수 있는 하드웨어뿐만 아니라 전용 하드웨어의 사용을 통해 제공될 수 있다. 프로세서에 의해 제공될 때, 기능들은 단일 전용 프로세서에 의해, 단일 공유 프로세서 또는 다수의 개별적인 프로세서들에 의해 제공될 수 있고 이것들의 일부는 공유될 수 있다. 게다가, 용어 "프로세서"의 명시적 사용은 소프트웨어를 실행할 수 있는 하드웨어만을 언급하는 것으로 해석되어서는 안되며, 디지털 신호 처리기(DSP) 하드웨어, 네트워크 프로세서, 응용 주문형 집적 회로(ASIC), 필드 프로그래머블 게이트 배열(FPGA), 소프트웨어를 저장하기 위한 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 비-휘발성 저장장치를 제한 없이 넌지시(implicitly) 포함할 수 있다.

또한, 시스템(102)은 인터페이스(들)(110)을 포함한다. 인터페이스들(110)은 시스템(102)으로 하여금 네트워크(106)의 엔티티들과 또는 서로서로 상호작용하게 하는 다양한 소프트웨어 및 하드웨어 인터페이스들을 포함할 수 있다. 인터페이스들(110)은 유선 네트워크들, 예를 들어, LAN, 케이블, 등 및 무선 네트워크들, 예를 들어, WLAN, 셀룰러, 위성-기반 네트워크 등을 포함하는 넓은 다양한 네트워크들 및 프로토콜 타입들 내의 다수의 통신들을 촉진할 수 있다(facilitate).

본 발명 주제의 또 다른 실시예에서, 시스템(102)은 또한 메모리(112)를 포함할 수 있다. 메모리(112)는 프로세서(108)에 커플링될 수 있다. 메모리(112)는, 예를 들어 정적 기억 장치(SRAM:static random access memory) 및 동적 기억 장치(DRAM:dynamic random access memory)와 같은 휘발성 메모리, 및/또는 판독 전용 기억 장치(ROM:read only memory), 소거할 수 있는 프로그래머블 ROM, 플래시 메모리들, 하드 디스크들, 광 디스크들, 및 자성 테이프들과 같은 비-휘발성 메모리를 포함하는 분야에서 알려진 임의의 컴퓨터-판독가능한 매체를 포함할 수 있다.

더욱이, 시스템(102)은 모듈(들)(114) 및 데이터(116)를 포함할 수 있다. 모듈들(114) 및 데이터(116)는 프로세서들(108)에 커플링될 수 있다. 다른 것들 사이의 모듈들(114)은 특정 임무들 또는 실시 특정 추정 데이터 타입들을 수행하는 루틴들, 프로그램들, 객체들, 구성요소들, 데이터 구조들, 등을 포함한다. 모듈들(114)은 또한 연산 명령어들을 기초로 한 신호들을 조종하는 신호 프로세서(들), 상태 기계(들), 논리 회로들, 및/또는 임의의 다른 디바이스 또는 구성요소로서 구현될 수 있다.

더욱이, 모듈들(114)은 하드웨어, 프로세싱 유닛에 의해 실행된 명령어들, 또는 이들의 조합으로 실행될 수 있다. 프로세싱 유닛은 컴퓨터, 프로세서, 상태 기계, 로직 배열 또는 프로세싱 명령들을 할 수 있는 임의의 다른 알맞은 디바이스들을 포함할 수 있다. 프로세싱 유닛은 일반적인-목적 프로세서로 하여금 필요한 임무들을 수행하도록 하는 명령들을 실행하는 일반적인-목적 프로세서가 될 수 있고 또는 프로세싱 유닛은 필요한 기능들을 수행하기 위해 전용될 수 있다.

본 발명 주제의 또 다른 양상에서, 모듈들(114)은, 프로세서/프로세싱 유닛에 의해 실행될 때, 설명된 기능들 중 어느 것을 실행하는 기계-판독가능한 명령어들(소프트웨어)이 될 수 있다. 기계-판독가능한 명령어들은 전자 메모리 디바이스, 하드 디스크, 광 디스크 또는 다른 기계-판독가능한 저장 매체 또는 비-일시적 매체 상에 저장될 수 있다. 일 실시예에서, 기계-판독가능한 명령어들은 또한 네트워크 연결을 통해 저장 매체로 다운로드 될 수 있다.

일 실시예에서, 모듈(들)(114)은 요청 분석 모듈(122), 문의 모듈(124), 보고 모듈(126) 및 다른 모듈(들)(128)을 포함한다. 다른 모듈(들)(128)은 시스템(102)에 의해 수행된 어플리케이션들 또는 기능들을 보충하는 프로그램들 또는 코드화된 명령어들을 포함할 수 있다. 상기 실시예에서, 데이터(116)는 거래 데이터(130), 사용자 선호도 데이터(132) 및 다른 데이터(134)를 포함한다. 다른 것들 중에서 다른 데이터(134)는 모듈(들)(114)에서 하나 이상의 모듈들의 실행의 결과로서 처리되고, 수신되고 또는 생성된 데이터를 저장하기 위해 저장소(repository)로서 서빙(serve)할 수 있다. 데이터(116)가 시스템(102) 내부에 도시되긴 하지만, 데이터(116)가 시스템(102)에 커플링 될 수 있는 외부 저장소(도면에 도시되지 않음)에 속할 수 있는 것이 이해될 수 있다. 시스템(102)은 데이터(116)로부터 정보를 얻기 위해, 인터페이스(들)(110)를 통해 외부 저장소와 통신할 수 있다.

이전에 언급된 바와 같이, 시스템(102)은 사용자들과 다른 당사자들 사이에서 업데이트된 거래들의 상태를 추적하기 위한 상태 업데이트 요청을 수신하도록 구성된다. 일 실시예에서, 요청 분석 모듈(122)은 사용자 디바이스들(104) 중 어느 하나로부터 이러한 요청을 수신하도록 구성된다. 사용자는 사용자 디바이스(104)를 통해 상태 업데이트 요청을 시스템(102)에게 제공할 수 있다. 요청 분석 모듈(122)은 네트워크(106)로부터의 인터페이스(110)를 통해 상태 업데이트 요청을 수신할 수 있다. 상기 실시예에서, 상태 업데이트 요청은 시스템(102)에 의한 거래에 대해 업데이트된 상태의 추적에 영향을 줄 수 있는 추적 파라미터들 및 사용자 선호도들을 포함할 수 있다.

예를 들어, 그의 기차 예약의 상태를 추적하기를 원하는 사용자는 상태 업데이트 요청을 사용자 디바이스(104-1)로부터 시스템(102)으로 네트워크(106)를 통해 전송할 수 있다. 요청 분석 모듈(122)은 이러한 상태 업데이트 요청을 수신할 수 있다. 일 실시예에서, 요청 분석 모듈(122)은 수신된 상태 업데이트 요청에 특수한 고유의 레퍼런스 번호(URN:Unique Reference Number)를 생성할 수 있다. URN은 차후의 레퍼런스 및 신원확인 목적에 대한 시스템(102)을 가진 사용자의 상태 업데이트 요청과 연관된 레퍼런스 번호로서 이해될 수 있다. 예를 들어, 사용자는 통신 결함 또는 고장의 경우에, 자신의 상태 업데이트 요청의 상태에 대한 문의에 대한 URN을 참조할 수 있다.

더욱이, 시스템(102)은 또한 사용자에 의해 제공된 정보를 생성된 URN을 따라서 상태 업데이트 요청에 저장할 수 있다. 또한, 요청 분석 모듈(122)은 사용자 세부사항들을 사용자의 원하는 선호도들에 따라서 URN과 연관시킬 수 있다. 요청 분석 모듈(122)이 각 상태 업데이트 요청에 대해서 새로운 URN을 생성할 수 있다는 것이 이해될 것이다. 더욱이, 다수의 상태 업데이트 요청들이 다수의 사용자들로부터 수신되는 상황들에서, 각 메시지는 새로운 URN과 연관된다. 더욱이, 심지어 상이한 거래들에 대한 다수의 상태 업데이트 요청들이 단일 사용자로부터 수신되는 상황들에서, 각 상태 업데이트 요청은 요청 분석 모듈(122)에 의해 새로운 URN 번호와 연관된다.

설명된 바와 같이, 요청 분석 모듈(122)에 의해 수신된 상태 업데이트 요청은 사용자와 다른 당사자 사이의 거래의 상태를 추적하기 위해 추적 파라미터들 및 사용자 선호도들을 포함할 수 있다. 추적 파라미터들은 거래를 고유하게 결정하기 위해 요청 분석 모듈을 제공할 수 있는 다른 세부사항들에 따른 거래의 레퍼런스 번호와 같은 거래 세부사항들을 포함할 수 있다.더욱이, 추적 파라미터들은 또한 업데이트된 거래 상태가 감시될 수 있는 것을 통해 다른 당사자의 세부사항들을 포함할 수 있다.

예를 들어, 병원, 말하자면, 아폴로 메디케어와의 예약의 상태를 추적하기 위해, 추적 파라미터는 임의의 사용자와 아폴로 메디케어 사이의 거래의 상태가 특정 거래 세부사항들을 기초로 추적될 수 있는 것을 통해 아폴로 메디케어의 웹사이트의 URL을 포함할 수 있다. 이것이 사용자의 이익에 대한 상태의 추적을 허용할 수 있는 것을 통해, 다른 당사자가 다수의 기술들 및 방법들을 지원하고 제공할 수 있다는 것이 이해될 것이다. 또한, 일부 다른 당사자들은 또한 사용자들로 하여금 사용자들의 거래의 상태를 추적하도록 하는 단일 기술의 다수의 채널들을 또한 제공할 수 있다. 예를 들어, IRCRC는 사용자들로 하여금 사용자들의 예약의 상태를 웹 인터페이스를 통해, SMS 조회를 통해 또는 IVRS에 의해 추적하도록 할 수 있다. 다수의 기능들의 이용도는 사용자들로 하여금 사용자들의 필요와 이용가능한 자원들에 따라서 상이한 방법들에서 선택하도록 한다. 더욱이, 사용자들에게 효율적인 서비스를 촉진하기 위해, IRCTC는 또한 사용자들의 예약의 상태를 추적하는 다수의 웹 포털들과 여러 IVRS 수신자 부담 전화번호들을 제공할 수 있다. 거래의 상태를 추적하는 하나 이상의 가능한 방법이 존재하는 상황들에서, 사용자는 임의의 특정 방법을 선택할 수 있고 상태 업데이트 요청에서 추적 파라미터들을 통해 시스템(102)과 동일한 것을 나타낼 수 있다. 예를 들어, 사용자 디바이스(104-1)를 통해 상태 업데이트 요청을 제공하는 사용자는 IVRS의 세부사항들보다도 예약을 추적하기 위해 IRCTC에 의해 제공된 웹 포털의 세부사항들을 제공할 수 있다. 시스템(102)은 거래 데이터(130) 내의 각 URN에 대해서 거래 세부사항들을 저장할 수 있다.

게다가, 사용자들은 또한 상태가 추적될 수 있는 다수의 웹 포털들 및 수신자 부담 전화 번호들(toll free numbers)을 선택할 수 있다. 예를 들어, IRCTC에 의해 제공된 다수의 웹 포털들 사이에서부터, 사용자는 자신의 개인 선호도를 기반으로 단일 웹 포털의 세부사항들을 오직 제공할 수 있다. 사용자가 다수의 이용가능한 옵션들로부터 상태 추적의 특정 방법들을 선택할 수 있다는 것이 설명되었지만, 사용자가 자신의 개인 선호도를 기반으로 하나 이상의 가능한 옵션들을 선택할 수 있다는 것이 이해될 것이다.

사용자가 다른 당사자의 세부사항들을 제공할 수 있다는 것이 설명되었지만, 그러나, 일 실시예에서, 요청 분석 모듈(122)은 상태 업데이트의 서비스가 사용자에게 제공될 수 있는 다른 당사자들의 목록을 제공할 수 있다. 옵션들의 제공된 목록으로부터, 사용자는 사용자가 거래를 완료했던 다른 당사자를 선택할 수 있다. 이러한 구현에서, 시스템(102)은 상인들, 공금자들, 의료 소스들, 예약 포털들 및 그들의 거래들의 상태를 추적하는 서비스를 제공할 수 있는 다른 당사자들의 총망라한 목록을 제공할 수 있다.

설명된 바와 같이, 시스템(102)의 요청 분석 모듈(122)은 각 상태 업데이트 요청을 새로운 URN과 연관시킬 수 있다. 일 실시예에서, URN은 또한 그의 레퍼런스에 대해 사용자에게 제공될 수 있다. 사용자는 시스템(102)과의 통신, 상태 업데이트 요청을 취소하는 것, 사용자 선호도들을 수정하는 것 및 추적 파라미터들을 변경하는 것을 위해서와 같은 다양한 목적들을 위해 URN을 활용할 수 있다.

일 실시예에서, 상태 업데이트 요청은 또한 상태 업데이트 요청에 설명된 거래의 상태를 추적하기 위한 사용자 선호도들을 규정할 수 있는 업데이트 파라미터들을 포함할 수 있다. 업데이트 파라미터들은 업데이트 빈도, 업데이트 기간, 업데이트 모드 및 업데이트의 시간을 포함할 수 있지만, 이에 제한되는 것은 아니다. 사용자는, 추적 파라미터들에 따라서, 거래의 상태를 추적하기 위해 그의 선호도들을 제공하는 업데이트 파라미터들을 제공할 수 있다. 업데이트 빈도는 사용자가 거래의 상태를 수신하기를 원하는 빈도로 규정할 수 있다. 주파수는 사용자의 선호도에 따라서 시간, 일 또는 주에 따라 규정될 수 있다. 더욱이, 업데이트의 기간은 업데이트가 사용자에 의해 원해질 수 있는 시간 기간을 나타낼 수 있다. 예를 들어, 한 사용자는 거래에 대한 상태 업데이트를 3일 동안만 수신하기를 원할 수 있다. 유사하게, 또 다른 사용자는 업데이트의 기간을 1주 또는 한 달로 규정할 수 있다. 업데이트 파라미터들이 사용자 선호도들을 나타내고 임의의 이러한 선호도들이 없을 시에, 요청 분석 모듈(122)에 의해 기본 값들이 추정될 수 있다는 것이 이해될 것이다. 그러나, 간결성을 위해, 기본 값이 규정되지 않았다 할 지라도, 시스템(102)이 상이한 업데이트 파라미터들에 대해 상이한 기본 값들을 규정할 수 있다는 것이 이해될 것이다. 더욱이, 시스템(102)은 또한 사용자에 대해 기본 값들의 특정 세트가 적용될 수 있는 상이한 사용자들에 대한 기본 값들의 상이한 세트를 규정할 수 있다.

본 발명 주제의 또 다른 실시예에서, 다른 당사자들의 총망라한 목록을 사용자에게 제공하는 것과 유사하게, 시스템(102)은 업데이트 파마리터들의 옵션을 사용자에게 제공하도록 구성될 수 있다. 사용자들은 사용자들이 가치를 제공할 수 있는 것에 대해서 파라미터들을 제공받을 수 있다. 예를 들어, 사용자 디바이스(104-1)를 활용하는 사용자는 그가 거래에 대한 상태 업데이트들을 수신하기를 원하는 빈도를 제공하도록 시스템(102)에 의해 요청받을 수 있다. 유사하게, 시스템(102)은 또한 업데이트 기간, 업데이트 모드 및 업데이트 시간과 같은 다른 세부사항들을 요청할 수 있다. 사용자에 의해 제공받은 업데이트 파라미터들은 시스템(102)에 의해 사용자 선호도 데이터(132)에 저장될 수 있다.

또 다른 실시예에서, 사용자 레퍼런스들을 제공하는 업데이트 파라미터들은 사용자에 의해 한 번 규정될 수 있고 시스템(102)은 사용자로부터 수신된 연속적인 다른 상태 업데이트 요청들에 대해 동일한 업데이트 파라미터들을 활용할 수 있다. 이것은 사용자들로 하여금 그들의 선호도들을 한 번 규정하도록 할 수 있고 상이한 요청들에서 사용자들에 의해 되풀이해서 제공받도록 요구된 정보를 줄일 것이다. 비록 사용자가 차후의 요청들에 대해 업데이트 파라미터들의 세트를 선택할 수 있지만, 사용자는 또한 특정한 상태 업데이트 요청에 대한 새로운 업데이트 파라미터들을 규정하는 것을 선택할 수 있다는 것이 이해될 것이다. 사용자의 거래 세부사항들을 제공하는 추적 파라미터들이 거래에 특수하다는 것과 사용자로부터 차후의 요청들에 대해 적용될 수 없다는 것이 추가로 이해될 것이다. 그러므로, 추적 파라미터들은 각 상태 업데이트 요청에 대해 사용자들에 의해 제공될 수 있다.

본 발명 주제의 일 실시예에서, 거래에 대해 제공된 추적 파라미터들 및 업데이트 파라미터들은 사용자에 의해 업데이트되고 수정될 수 있다. 다시 말하면, 사용자는 추적 및 업데이트 파라미터들의 세트를 변경할 수 있다. 이를 위해, 사용자는 요청 수정 메시지를 시스템(102)에 네트워크(106)를 통해 전송할 수 있다. 요청 수정 메시지는 사용자가 파라미터들에 대한 새로운 가치들에 따른 파라미터들을 수정하기를 원하는 URN을 포함할 수 있다. 시스템(102)이 URN을 기반으로 각 메시지에 대해 사용자 선호도들에 따른 거래 세부사항들을 저장하고 그러므로 파라미터들의 수정에 대한 URN을 제공하는 것은 특정 URN에 연관된 파라미터들을 오직 수정할 것이 이해될 것이다.

사용자 선호도들을 규정하는 추적 파라미터들과 업데이트 파라미터들에 따른 상태 업데이트 요청을 수신하자마자, 시스템(102)은 상태 업데이트 요청에서 사용자에 의해 기입된 거래의 상태를 얻을 수 있다. 일 실시예에서, 시스템(102)의 문의 모듈(124)은 거래의 상태를 얻기 위해 다른 당사자를 조회하도록 구성된다. 상기 실시예에서, 문의 모듈(124)은 거래 데이터(130)로부터 문의 모듈(124)에 의해 수신된 사용자의 요청과 연관된 거래 세부사항들을 활용할 수 있다.

또 다른 실시예에서, 문의 모듈(124)에 의해 수신된 거래의 상태는 네트워크(106)를 통해 사용자에게 제공될 수 있다. 상기 실시예에서, 보고 모듈(126)은 업데이트 파라미터들을 기초로 거래의 상태를 사용자에게 제공하도록 구성된다. 즉, 보고 모듈(126)은 이러한 선호도들을 기초로 상태 업데이트의 보고에 관련한 사용자 선호도들을 결정할 수 있고 상태 업데이트를 사용자에게 제공할 수 있다. 업데이트들을 매일 수신하기를 원하는 사용자를 위해, 보고 모듈(126)은 거래의 상태 업데이트를 매일 제공할 수 있다. 유사하게, 또 다른 사용자는 거래의 상태가 확인되지 않은 시간까지 상태 업데이트를 제공하기 위해, 보고 모듈(126)이 상태를 또한 분석할 수 있는 것을 기초로 하여, 약속의 확인 이후에 바로 상태 업데이트들을 종료하기를 원할 수 있다.

유사하게, 사용자는 SMS 또는 전화통화들이 아닌 이메일들을 통해 그의 거래의 업데이트된 상태를 수신하는 것을 원할 수 있다. 이러한 상황에서, 통신 모드의 사용자 선호도를 기초로, 보고 모듈(126)은 이메일을 거래의 업데이트된 상태를 제공하는 사용자에게 전송할 수 있다. 추가로, 사용자는 또한 보고 모듈(126)이 상태 업데이트를 사용자에게 제공할 수 있는 것을 기초로 한 업데이트 시간으로서 11:00am을 규정할 수 있다. 상이한 사용자들은 이러한 선호도들을 기초로 하여 상이한 선호도들을 가질 수 있고, 그러므로 보고 모듈(126)은 업데이트된 거래들의 상태를 사용자들에게 제공할 수 있다는 것이 이해될 것이다.

도 2는 본 발명 주제의 일 실시예에 따른 사용자와 다른 당사자 사이의 거래의 상태 업데이트를 제공하기 위한 방법(200)을 도시한다. 방법(200)이 설명되는 순서는 제한으로서 해석되는 것으로 의도되지 않으며, 설명된 방법 블록들의 임의의 번호는 방법(200) 또는 임의의 대안적인 방법들을 실행하기 위해 합쳐질 수 있다. 추가로, 개별적인 블록들은 본 명세서에 설명된 본 발명 주제의 사상과 범위로부터 시작하지 않고 방법으로부터 삭제될 수 있다. 게다가, 방법은 임의의 알맞은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로 구현될 수 있다.

방법은 컴퓨터 실행가능한 명령어들의 일반적인 컨텍스트에서 설명될 수 있다. 일반적으로 컴퓨터 실행가능한 명령어들은 특정 기능들을 수행하는 또는 특정 추상적인 데이터 타입들을 구현하는 루틴들, 프로그램들, 객체들, 구성요소들, 데이터 구조들, 절차들, 모듈들, 기능들 등을 포함할 수 있다. 방법은 또한 기능들이 통신 네트워크를 통해 링크된 리모트 프로세싱 디바이스들에 의해 수행된 분포된 컴퓨팅 환경에서 실행될 수 있다. 분포된 컴퓨팅 환경에서, 컴퓨터 실행가능한 명령어들은 메모리 저장 디바이스들을 포함하는 로컬 및 리모트 컴퓨터 저장 매체 둘 모두에 위치할 수 있다.

당업자는 방법의 단계들이 프로그램화된 컴퓨터들로 수행될 수 있다는 것을 이미 인식할 것이다. 본 명세서에서, 일부 실시예들은 또한 컴퓨터 판독가능한 것을 커버하도록 의도되며 상기 명령어들이 설명된 방법의 단계들의 일부 또는 전체를 수행하는 명령어들의 기계-실행가능한 또는 컴퓨터-실행가능한 프로그램들을 인코드하도록 의도된다. 프로그램 저장 디바이스들은 예를 들어 디지털 메모리들, 자기 디스크들 및 자기 테이프들과 같은 자기 저장 매체, 하드 드라이브들, 또는 광학적으로 판독가능한 디지털 데이터 저장 매체일 수 있다. 실시예들은 또한 예시적인 방법들의 상기 단계들을 수행하도록 구성된 통신 네트워크와 통신 디바이스들 둘 모두를 커버하도록 의도된다.

도 2를 참조하여, 블록(202)에서, 상태 업데이트 요청은 사용자와 다른 당사자 사이의 거래의 상태를 추적하기 위해 사용자로부터 수신된다. 본 발명 주제의 일 실시예에서, 사용자는 상태 업데이트 요청을 USSD 메시지, SMS, IVRS, 이메일 및 다른 것들과 같은 방법들을 활용하는 통신 네트워크를 통해 상태 업데이트 요청을 제공할 수 있다. 상기 실시예에서, 거래의 업데이트된 상태를 사용자에게 제공하기 위해, 상태 업데이트 요청은 통신 네트워크의 엔티티 또는 서비스 제공자에 의해 수신될 수 있다.

블록(204)에서, 적어도 상태 업데이트 요청과 연관된 추적 파라미터들 및 업데이트 파라미터들이 확인된다(identify). 추적 파라미터들은 사용자가 상태를 추적하기를 원하는 다른 당사자의 세부사항들과 거래 세부사항들을 제공할 수 있다. 업데이트 파라미터들은 거래의 추적 상태와 관련된 사용자 선호도와 업데이트들의 통신을 사용자에게 다시 제공할 수 있다. 일 실시예에서, 업데이트 파라미터들은 업데이트 빈도, 업데이트 기간, 업데이트 모드 및 업데이트 시간을 포함할 수 있으나 이제 제한되는 것은 아니다.

블록(206)에서, 다른 당사자는 거래의 업데이트된 상태를 얻기 위해 추적 파라미터들과 업데이트 파라미터들을 기초로 폴링된다. 일 실시예에서, 시스템(102)은 거래의 상태를 얻기 위해 다른 당사자를 폴링한다. 설명된 바와 같이, 거래 세부사항들은 상태 업데이트 요청에 따라 수신된 추적 파라미터들을 따라 수신된다. 폴링이 상태 업데이트 요청에서 규정된 업데이트 파라미터들에 따라 수행될 수 있다는 것이 이해될 것이다.

블록 (208)에서, 거래의 업데이트된 상태는 업데이트 파라미터들을 기초로 사용자에게 제공된다. 설명된 바와 같이, 업데이트 파라미터들은 업데이트 빈도, 업데이트 모드 및 상태 업데이트 시간을 규정할 수 있고 그러므로, 거래의 업데이트된 상태는 업데이트된 파라미터들을 기초로 사용자에게 제공될 수 있다.

거래의 업데이트된 상태를 제공하기 위한 방법들 및 시스템들에 대한 실시예들이 구조적 특징들 및 / 또는 방법들에 특수한 언어로 설명되었지만, 발명은 설명된 특정 특징들 또는 방법들에 반드시 제한되지 않는다는 것이 이해될 것이다. 오히려, 특정 기능들 및 방법들은 거래들에 대한 상태 업데이트를 제공하기 위해 예시적인 실시예들로서 개시된다.

Claims (10)

1. 네트워크 환경에서 거래의 상태 업데이트를 제공하기 위한 방법에 있어서:
   사용자와 다른 당사자 사이의 상기 거래의 상태를 추적하기 위해, 상기 사용자의 통신 디바이스로부터 서버에 의한 상태 업데이트 요청을 수신하는 단계로서, 상기 상태 업데이트 요청은 상기 상태 업데이트와 연관된 추적 파라미터들 및 업데이트 파라미터들 중 적어도 하나를 포함하는, 상기 수신 단계;
   상기 거래의 업데이트된 상태를 얻기 위해, 상기 추적 파라미터들 및 상기 업데이트 파라미터들을 기초로 하여, 통신 네트워크를 통하여 상기 다른 당사자를 폴링(poll)하는 단계; 및
   상기 업데이트 파라미터들을 기초로 하여 상기 거래의 상기 업데이트된 상태를 상기 사용자의 상기 통신 디바이스에 제공하는 단계를 포함하고,
   상기 방법은 상기 사용자에 의해 상기 업데이트 파라미터들을 송신하는 단계를 더 포함하고, 상기 업데이트 파라미터들은 상태 업데이트의 빈도에 대한 상기 사용자의 선호도들을 규정하는 것을 특징으로 하는, 거래의 상태 업데이트를 제공하기 위한 방법.
2. 제 1 항에 있어서,
   상기 수신 단계는 USSD 메시지, SMS, 이메일 및 대화형 음성 응답 시스템들(IVRS:Interactive Voice Response Systems) 중 적어도 하나를 통해 상기 상태 업데이트 요청을 얻는 단계를 포함하는, 거래의 상태 업데이트를 제공하기 위한 방법.
3. 제 1 항에 있어서,
   상기 수신 단계는 또한 상기 사용자로부터의 별도의 메시지(separate message)에서 상기 거래와 연관된 상기 추적 파라미터들 및 상기 업데이트 파라미터들 중 적어도 하나를 얻는 단계를 포함하는, 거래의 상태 업데이트를 제공하기 위한 방법.
4. 제 3 항에 있어서,
   상기 얻는 단계는;
   상기 다른 당사자 세부사항들의 총망라한 목록(exhaustive list) 및 상기 업데이트 파라미터들을 상기 사용자에게 제공하는 단계; 및
   상기 추적 파라미터들 및 상기 업데이트 파라미터들에 상응하는 사용자 응답을 수신하는 단계를 포함하는, 거래의 상태 업데이트를 제공하기 위한 방법.
5. 제 1 항에 있어서,
   상기 상태 업데이트 요청은 고유의 레퍼런스 번호(URN:unique reference number)와 연관되고, 상기 URN은 상기 상태 업데이트 요청과 연관된 상기 추적 파라미터들 및 상기 업데이트 파라미터들의 고유의 식별을 허용하는, 거래의 상태 업데이트를 제공하기 위한 방법.
6. 거래의 업데이트된 상태를 제공하기 위한 시스템(102)에 있어서;
   프로세서(108);
   상기 프로세서(108)에 커플링 되고, 사용자와 다른 당사자 사이에 상기 거래의 상태를 추적하기 위해 사용자로부터 상태 업데이트 요청을 수신하도록 구성된 요청 분석 모듈(122)로서, 상기 상태 업데이트 요청은 상기 상태 업데이트와 연관된 추적 파라미터들 및 업데이트 파라미터들 중 적어도 하나를 포함하는, 상기 요청 분석 모듈(122);
   상기 프로세서(108)에 커플링 되고, 상기 거래의 업데이트된 상태를 얻기 위해 상기 추적 파라미터들 및 상기 업데이트 파라미터들을 기초로 상기 다른 당사자를 폴링하도록 구성된 문의 모듈(querying module)(124); 및
   상기 프로세서(108)에 커플링 되고, 상기 업데이트 파라미터들을 기초로 상기 거래의 상기 업데이트된 상태를 상기 사용자에게 제공하도록 구성된 보고 모듈(reporting module)(126)을 포함하고,
   상기 시스템은 상기 업데이트 파라미터들이 상태 업데이트의 빈도에 대한 상기 사용자의 선호도들을 규정하는 것을 특징으로 하는, 거래의 업데이트된 상태를 제공하는 시스템.
7. 제 6 항에 있어서,
   상기 요청 분석 모듈(122)은 또한 상기 사용자로부터 상기 거래와 연관된 상기 추적 파라미터들 및 상기 업데이트 파라미터들 중 적어도 하나를 얻도록 구성된, 거래의 업데이트된 상태를 제공하는 시스템.
8. 제 7 항에 있어서,
   상기 요청 분석 모듈(122)은:
   다른 당사자 세부사항들의 총망라한 목록 및 업데이트 파라미터들을 상기 사용자에게 제공하고;
   상기 추적 파라미터들 및 업데이트 파라미터들에 상응하는 사용자 응답을 수신하도록 구성된, 거래의 업데이트된 상태를 제공하는 시스템.
9. 제 6 항에 있어서,
   상기 요청 분석 모듈(122)은 또한 상기 상태 업데이트 요청을 고유의 레퍼런스 번호(URN)와 연관하도록 구성되고, 상기 URN은 상기 상태 업데이트 요청과 연관된 상기 추적 파라미터들 및 상기 업데이트 파라미터들의 고유의 식별을 허용하는, 거래의 업데이트된 상태를 제공하는 시스템.
10. 거래에 대한 상태 업데이트를 제공하기 위한 방법을 실행하기 위한 컴퓨터 프로그램을 가진 컴퓨터 판독가능한 매체에 있어서,
    상기 방법은:
    사용자와 다른 당사자 사이의 상기 거래의 상태를 추적하기 위해 상기 사용자로부터 상태 업데이트 요청을 수신하는 단계로서, 상기 상태 업데이트 요청은 상기 상태 업데이트와 연관된 추적 파라미터들 및 업데이트 파라미터들 중 적어도 하나를 포함하는, 상기 수신 단계;
    상기 거래의 업데이트된 상태를 얻기 위해 상기 추적 파라미터들 및 상기 사용자의 선호도들을 기초로 상기 다른 당사자를 폴링하는 단계; 및
    상기 사용자의 선호도들을 기초로 상기 거래의 상기 업데이트 된 상태를 상기 사용자에게 제공하는 단계를 포함하고,
    상기 방법은 상기 사용자에 의해 상기 업데이트 파라미터들을 송신하는 단계를 더 포함하고, 상기 업데이트 파라미터들은 상태 업데이트의 빈도에 대한 상기 사용자의 선호도들을 규정하는 것을 특징으로 하는, 컴퓨터 판독가능한 매체.

Images