KR20050058326A

KR20050058326A - 물류시스템 사용자에게 통지를 전송하는 방법 및 시스템

Info

Publication number: KR20050058326A
Application number: KR1020057002638A
Authority: KR
Inventors: 메이어 보리스; 산텔 요하네스
Original assignee: 도이체 포스트 아게
Priority date: 2002-08-16
Filing date: 2003-08-06
Publication date: 2005-06-16
Also published as: NO20050332L; PL375397A1; ES2316855T3; AU2003266105A1; ZA200501326B; ATE417331T1; JP2005539294A; WO2004019241A1; DE50310903D1; CA2498038A1; EP1530771A1; NO332028B1; BR0312488A; EP1530771B1; US20060085273A1; PT1530771E; HK1077377A1; CA2498038C; DK1530771T3; RU2005101750A

Abstract

본 발명은 물류시스템 사용자에게 통지를 전송하기 위한 방법 및 시스템에 관한 것이다. 본 발명은 물류시스템 내에서 서로 다른 이벤트에 따라, 관련된 함수들을 갖는 다른 모듈들이 각각의 경우에 호출되고, 그럼으로써 상기 모듈들은 중앙송신요소(30)로 전송되는 통지명령을 생성하고, 그 통지명령을 바탕으로, 상기 중앙송신요소(30)는 적절한 통지들을 생성하여 상기 사용자에게 전송하는 것을 특징으로 한다. 또한, 상기 사용자에게 통지를 전송하는 방법을 실행하는 방법이 개시된다.

Description

물류시스템 사용자에게 통지를 전송하는 방법 및 시스템 {METHOD AND SYSTEM FOR TRANSMITTING NOTIFICATIONS TO USERS OF A LOGISTIC SYSTEM}

본 발명은 물류시스템 사용자에게 통지를 전송하기 위한 방법 및 시스템에 관한 것이다.

복수의 사용자와 하나 이상의 물류제공자를 가지는 물류시스템을 동작시키기 위해서, 소정의 정보는 그 물류시스템의 가입자들에게 전송되어야만 한다. 정보의 전송은 이 후부터는 통지를 가리킨다. 상기와 같은 통지는 하나 또는 그 이상의 다른 통신을 통하여 발생한다.

통지는 물류시스템 내에서 발생하는 이벤트들을 바탕으로 전송된다. 이러한 맥락에서, 물류시스템의 이벤트는 어떠한 통지를 트리거(trigger)할 수 없거나 하나 또는 그 이상의 통지를 트리거할 수 있다. 통지에 대하여 물류시스템의 이벤트의 할당은 비즈니스 로직(business logic)의 기능으로서 통지 성분 내에서 실행될 수 있다.

통지는 다른 형태의 통신을 통하여 전달될 수 있다. 여기서, 통신의 형태는 하나의 통지가 전달되는 방식이다. 원칙적으로, 같은 정보 내용을 가진 통지는 여러 형태의 통신을 통하여 전달될 수 있다.

특히 등록된 사용자를 위한 소포 컴파트먼트 시스템(parcel compartment system)이 수송 및 전달 회사에 의하여 동작될 때 다른 통지들 (different notifications) 및 여러 형태의 통신(types of communication)을 가지는 물류시스템이 필요하다. 이와 같은 소포 컴파트먼트 시스템(parcel compartment system) 또는 자동소포전달기계(automatic parcel delivery machines)는, 예를 들어, 등록된 사용자들을 위한 우편 서비스 제공자들에 의하여 동작된다. 여기서, 전달자는 등록된 사용자들을 위하여 소포 또는 다른 하물 (shipments)을 상기 시스템으로 보낸다. 그러면 소정의 소포가 그 사용자에게 전달될 것임을 그 사용자에게 통지되어야 한다. 게다가, 물류시스템은, 예를 들어, 사용자가 그 소포를 집배(pick-up)했는지에 대하여 정보를 받게 해야 한다. 또한, 신규 클라이언트의 정보, 클라이언트 데이터, 집배 기한 및 COD 요금에 대한 정보가 물류시스템과 교환되어야 한다.

소포 컴파트먼트 시스템을 위한 물류시스템 내에서, 일반적으로 통지는 전자우편 또는 SMS로 전송된다. 바람직하게는, 통지의 생성, 관리 및 전송은 여러 데이터베이스를 필요로 하고 또한 그 처리 순서를 필요로 한다.

물류시스템 사용자는 상품(goods)을 분배하는 것으로 알려져 있다. 분배될 상품은 모든 종류의 제품, 재료 및 물건이 될 수 있다. 물류시스템은 해당하는 상품의 분배를 위하여, 예를 들어, 여러 다른 수송 경로에 대하여, 창고, 중간 보관 시설, 컨테이너, 차량, 발신자 및 수신들 사이의 관계를 조직하고 감시한다. 물류시스템의 기능은, 예를 들어, 운송경로, 수용 활용성, 저장시간 및 데이터 전송에 대하여, 그 상품이 최적으로 분배될 수 있도록, 필요조건을 유리하게 적용한다.

신청자는 서신 및 상품(소포, 소하물), 운송상자, 화물 운반대 및 컨테이너를 분배하기 위하여 물류시스템을 적절하게 이용한다. 바람직하게는, 관계된 물류시스템은 발송자와 수신자 사이의 하물을 분배하고, 그로 인하여, 운송 속력, 창고 및 차량의 이용성, 및 하물 데이터의 전송과 같은 판단 기준을 이용한다.

예를 들어, 독일 실용신안 제201 03 564 U1호에는 전자 상거래에 특히 적절한 하물을 전달하고 수신하는 시스템이 개시되어 있다. 그 시스템은 화물을 저장되고 집배하는 여러 자동 전달 기계 (automatic delivery machine (ADM))를 포함한다. 또한 그 시스템에는 그 시스템의 동작을 다루기 위한 라미스(LAMIS) 서버-컴퓨터 프로그램이 포함되어 있다. 예를 들어, 클라이언트가 전자우편과 같은 여러 통신 형태를 통하여 ADM에 있는 그 클라이언트를 위하여 적재된 화물에 대하여 정보를 받는다.

도 1은 본 발명의 실시예에 따라, 외부 인터페이스, 중앙송신요소 및 통신요청 큐 사이에 처리 순서를 나타낸 구성도이다.

도 2는 본 발명의 실시예에 따라, 통신요청 큐, 중앙송신요소 및 전송계약 로직 사이의 처리 순서를 나타낸 구성도이다.

도 3은 중앙송신요소, 여러 데이터베이스 및 게이트웨이 사이의 처리 순서를 나타낸 구성도이다.

도 4는 통지를 전송하는 시스템 내에서 순서들에 대한 일반적인 개요를 나타낸 구성도이다.

<도면 부호에 대한 간단한 설명>

10: 외부 인터페이스

20: 전달계약 로직 (delivery contract logic)

30: 중앙송신요소 (central sending component)

40: 통신요청 큐 (communication request queue)

41: 타이머 50: 큐 읽개 (queue reader)

70: 클라이언트 데이터베이스 80: 소포 데이터베이스

90: 자동소포전달기계 100: 자료 데이터베이스

110: 템플릿 120: 게이트웨이

본 발명의 목적은 물류시스템 내에서 다른 이벤트들에 가장 융통성 있게 응답할 수 있고 사용자-지정 통지를 생성할 수 있게 하는 물류시스템 사용자에게 통지를 전송하는 방법을 제공하는 데에 있다.

상기 본 발명에 따른 목적은, 물류시스템 내에 있는 다른 이벤트들에 대응하여, 연관된 기능들을 갖는 다른 모듈들이 각 경우에 호출되고, 그로 인하여 상기 모듈들이 통지 명령(notification orders)을 생성하고, 그 통지명령은 중앙송신요소로 전송됨으로써 달성된다. 여기서, 상기 중앙송신요소는, 상기 통지명령을 바탕으로 적당한 통지를 생성하여 사용자들에게 전송한다.

본 발명의 다른 목적은 상기 방법을 실행하는 시스템을 제공하는 데에 있다.

이를 위하여, 물류시스템 내에서 이벤트들에 대응하는, 관련된 기능을 갖는 모듈은 외부 인터페이스를 형성하며, 그 외부 인터페이스를 통하여 사용자 케이스(User Cases)가 매핑된다. 본 발명의 바람직한 실시예에서, 상기 모듈에 의하여 생성되는 통지명령은 특별한 경우에 상기 중앙송신요소로 직접 송신되고, 반면에 그 통지명령은 통신요청 큐에 저장된다. 큐 읽개(queue reader)는 타이머-제어 방식으로 통신요청 큐로부터 그 통지명령을 읽어서 중앙송신요소로 전송한다. 상기 수행과정 전에, 통지의 상태는 점검된다. 예를 들어, 소포가 해당 과정에서 집배되거나 그 소포를 집배하는 사람이 변경됨으로써, 그 상태는 변경될 수 있다.

본 발명의 제1태양에 따라, 중앙송신요소는 하나 또는 그 이상의 데이터베이스로부터 출력된 데이터를 바탕으로 통지를 생성한다. 상기 데이터베이스는, 적어도 클라이언트 데이터베이스, 소포 데이터베이스, 자동소포전달기계 데이터베이스 및 자료 데이터베이스를 포함한다. 예를 들어, 클라이언트 데이터베이스는 물류시스템의 등록된 클라이언트들에 대하여 데이터를 포함하고, 그로 인하여 각 클라이언트는 식별 목적을 위하여 하나의 식별번호(ID)를 받는다. 상기 데이터는 주소, 전화번호 또는 다른 정보를 포함한다. 상기 소포 데이터베이스는 그 시스템 내에서 운송된 소포에 대한 정보를 포함하고, 그로 인하여 소포는 하나의 식별번호(ID)의 수단에 의해서도 식별된다. 상기 자동소포전달기계 데이터베이스는 그 시스템 내에서 사용된 소포 컴파트먼트 시스템에 대하여 정보를 포함한다. 마찬가지로, 상기 자동소포전달기계 데이터베이스는 식별번호들(IDs)을 포함한다.

상기 자료 데이터베이스는 사용자-지정 통지를 생성하기 위한 템플릿을 포함한다. 이와 같은 목적을 위하여, 바람직하게는, 상기 자료 데이터베이스는 전자우편 통지 및 SMS 통지를 위한 템플릿을 포함한다. 그 템플릿은 상기 데이터베이스로부터 출력된 사용자-지정 데이터가 삽입되는 플레이스홀더 (placeholders)를 가진다.

상기 중앙송신요소는 생성된 통지가 사용자에게 송신될 수 있도록 게이트웨이로 그 생성된 통지를 전송한다.

본 발명의 부가적인 이점, 특징 및 실시예는, 도면을 참조하여, 첨부한 특허청구범위와 앞으로 설명할 본 발명의 바람직한 실시예의 설명으로부터 더 명확해진다.

이하에서는, 등록된 사용자의 가변적인 수를 가지는 하나 또는 그이상의 소포 컴파트먼트 시스템을 포함하는 시스템을 동작시키는 물류시스템에 대하여 설명된다. 상기 물류시스템은 본 발명의 실시예지만, 본 발명에 따른 방법은 통지를 송신하는 다른 로직 시스템들에게도 적용될 수 있다.

예를 들어, 하나 또는 그 이상의 소포 컴파트먼트 시스템을 동작시키는 물류시스템은, 그 기능을 바탕으로 하여, 최소한 다음 처리 단계들로 구분된다.

UC BNK1 클라이언트 등록확인 단계

UC BNK2 클라이언트 데이터 변경 단계

UC BNK3 '신규 소포' 통지 단계

UC BNK5 '소포가 집배되었음'을 나타내는 통지 단계

UC BNK6 '소포가 돌아왔음'을 나타내는 통지 단계

UC BNK7 '추가된 대체' 통지 단계

UC BNK8 '삭제된 대체' 통지 단계

시스템 내에 있는 상기 이벤트들을 위하여, 통지들은 사용자에게 송신되고 이들 통지들은 사용자에게 그 이벤트들을 알려주고 또는 그 이벤트들을 확인시킨다. 본 발명의 바람직한 실시예에서, 개별 처리단계의 실행은 여러 모듈들 및/또는 물류시스템의 유니트들(units)에 의하여 수행된다. 이들 모듈들은, 예를 들어, 클라이언트 데이터베이스, 물류시스템을 위한 등록 유니트 또는 시스템 관리 유니트가 될 수 있다. 이들 모듈은, 선택적으로 다른 요소들과 함께, 외부 인터페이스(10)를 형성한다.

모듈들 내에서 호출절차의 순서와 함수에 대하여 상세하게 설명한다. 모듈들에 의하여 생성되는 통지명령들은 그 명령들이 즉시 송신될 수 있도록 중앙송신요소(30)로 이송되거나 (transferred) 그 명령들이 지연방식으로 전송될 수 있도록 통신요청 큐(40)에 저장된다. 모든 대기 명령들은 상기 큐에서 일정하게 읽혀지고적절한 통지들이 송신된다. 생성된 통지들은 바람직하게는 전자우편 또는 SMS를 통해 송신된다.

UC BNK1 클라이언트 등록확인 단계

소포 컴파트먼트 시스템의 물류시스템에 대하여 신규 클라이언트가 등록된 후에, 등록 모듈은 확인 통지를 송신하기 위하여 소정의 다음 함수를 호출한다:

newRecipient (User)

상기 함수는 클라이언트와 연관된 클라이언트들의 클라이언텔리 로직 (clientele logic)을 바탕으로 필요한 통지를 결정하고, 상기 함수는 통지들이 지연방식으로 송신될 수 있도록 통신요청 큐로 그 통지를 입력한다.

UC BNK2 클라이언트 데이터 변경 단계

소정의 클라이언트는 클라이언트 데이터베이스에 저장된 클라이언트를 변경하고, 클라이언트 데이터베이스는 확인 통지를 송신하기 위하여 다음 함수를 호출한다.

updateRecipent(User)

마찬가지로, 상기 함수는 클라이언트와 연관된 클라이언트들의 클라이언텔리 로직(clientele logic)을 바탕으로 필요한 통지를 결정하고, 상기 함수는 통지들이 지연방식으로 송신될 수 있도록 통신요청 큐로 그 통지를 입력한다.

UC BNK3 '신규 소포' 통지 단계

소정의 소포가 물류시스템의 자동소포전달기계에 전달될 때, 이 결과에 대한 정보는 물류시스템을 위한 시스템 관리 유니트에 송신된다. 물류시스템을 위한 시스템 관리 유니트는 확인통지를 송신하기 위하여 다음 함수를 호출한다.

notifyDelivery (Parcel)

상기 함수는 상기 소포와 연관된 클라이언트들의 클라이언텔리 로직을 바탕으로 필요한 통지를 결정하고, 상기 함수는 통지들이 지연방식으로 송신될 수 있도록 통신요청 큐로 그 통지를 입력한다.

UC BNK5 '소포가 집배되었음'을 나타내는 통지 단계

소정의 소포가 물류시스템의 자동소포전달기계로부터 집배되었을 때, 그 결과에 대한 정보는 물류시스템에 대한 상기 시스템 관리 유니트로 송신된다. 그 다음에 상기 물류시스템에 대한 시스템 관리 유니트는 다음 함수를 호출한다.

notifyPickup (Parcel)

상기 함수는 상기 소포와 연관된 클라이언트들의 클라이언텔리 로직을 바탕으로 필요한 통지를 결정하고, 상기 함수는 통신요청 큐로 그 통지를 입력한다.

UC BNK6 '소포가 돌아왔음'을 나타내는 통지 단계

소정의 집배 기한 전에 소정의 소포가 집배되지 않았기 때문에 그 소포가 물류시스템의 자동소포전달기계로부터 되돌아왔을 때, 그 결과에 대한 정보는 물류시스템에 대한 시스템 관리 유니트로 송신된다. 물류시스템을 위한 시스템 관리 유니트는 확인 통지를 송신하기 위하여 다음 함수를 호출한다.

parcelFailed (Parcel)

UC BNK7 '추가된 대체' 통지 단계

소정의 대체가 물류시스템의 자동소포전달기계에서 대기 소포(waiting parcel)에 대하여 추가되었을 때, 그 결과에 대한 정보는 물류시스템에 대한 시스템 관리 유니트로 송신된다. 그 다음에 물류시스템용 시스템 관리 유니트는 확인 통지를 송신하기 위하여 다음 함수를 호출한다.

addSubstitute (Parcel, User)

UC BNK8 '삭제된 대체' 통지

소정의 추가된 대체가 물류시스템의 자동소포전달기계에서 대기 소포에 대하여 삭제되었을 때, 그 결과에 대한 정보는 물류시스템에 대한 시스템 관리 유니트로 송신된다. 그 다음에 물류시스템용 시스템 관리 유니트는 확인 통지를 송신하기 위하여 다음 함수를 호출한다.

removeSubstitute (Parcel, User)

아울러, 예를 들어, 다음 이벤트들은 모듈들 내의 함수들에 의하여 매핑될 수 있다:

함수가 아닌 자동소포전달기계

notifyADMfailed (Parcel parcel, Boolean failure)

포괄통지

genericNotilication (Parcel parcel, Addressable add, int type)

전달 제공자에 대한 통지: 전달된 소포

notifyDeliveryProvider(Parcel parcel)

전달 제공자에 대한 통지: 삭제된 소포

notifyPickupProvider(Parcel parcel)

분기

notifyBranch (String description, DeliveryMachine adm, Addressable recipient, Boolcan branchCODparcel)

제품 잠금

notifyWarehouseDelivery (String description, DeliveryMachine adm, Addresable recipient)

실패한 주소 점검

notifyAdressCheckFailed(String description, Addressable recipient)

인터넷 비밀번호

notifyOnternetPassword(string description, Addrsssable recipient)

포괄 메시지 텍스트

notifyGenericMessageText(String description, Addressable recipient)

제공자에게 되돌려주는 전달

notifyDeliveryReturnsProvider(Parcel parcel)

제공자에게 되돌려주는 집배

notifyPickupByDeliveryAgentProvider(Parcel parcel)

전달 에이전트 제공자에 의한 집배

notifyPickupByDeliveryAgentProvider(Parcel parcel)

변경된 전자우편

notifyEmailChanged(Addressable recipient)

변경된 이동 전화기 번호

notifyMobileNumberChanged(Addressable recipient)

변경된 우편 PIN

notifyPostPinChanged(Addressable recipient)

변경된 비밀번호

notifyPostPasswordChanged(Addressable recipient)

바람직하게는, 통지는 전자우편 또는 SMS 폼(form)으로 송신된다. 이를 위하여, 예를 들어, 전자우편 또는 SMS 게이트웨이가 이용될 수 있다.

본 발명의 실시예에 따른 방법을 이용하기 위하여, 전달될 수 없는 통지들의 목록이 일정한 간격(예를 들어, 24시간 마다)으로 수동적으로 수정되는 것이 유리하다는 것이 증명되었다.

도1 내지 도4는 본 발명에 따른 시스템의 바람직한 실시예에서 주요부의 요소들을 나타낸 구성도이다. 외부 시스템은 빗금으로 표시되었고, 반면에 통지 시스템에 속하는 부분들(parts)은 흰색으로 나타낸다.

도1은 통지 요소의 바람직한 실시예의 구조를 나타낸 구성도이다. 통지 요소는 외부 인터페이스(10)와 연결되고, 이 외부 인터페이스는 물류시스템에서 소정의 이벤트들이 발생할 경우에 외적으로 호출된다. 상기 인터페이스는 여러 모듈들로 이루어져 있고, 각각의 모듈은 해당하는 함수들을 갖는다. 물류시스템의 이벤트들은 B2B 계정 로직 요소 (나타내지 않음)에 의한 통지명령으로 변환된다. 소정의 특별한 경우에 대하여, 상기 통지명령은 중앙송신요소(30)을 통하여 직접 송신될 수 있다. 그러나 표준절차로서, 상기 명령들은 통신요청 큐(40)에 기록되고 타이머-제어 방식으로 상기 중앙송신요소(30)로 전송된다. 예를 들어, 이는 촉구 통지(reminder notifications)가 적절한 시간 내(예를 들어, 2일 후 또는 7일 후)에 이후 시점에 정의되게 한다. 또한 큐에 기록되는 과정은 실패된 송신 시도가 큐에서 자동적으로 반복될 수 있게 한다는 점에서 이점이 있다.

도2는 통지 명령이 통신요청 큐(40)에 기록된 후의 처리 순서를 나타낸 구성도이다. 통신요청큐(40)에 있는 명령은 타이머-제어 방식으로 큐읽개(50)에 의하여 읽혀진다. 점검 절차가 B2B 전달 계약 로직(20)에 대하여 그 상태가 소정의 시간 (in the meantime)내에 변경되었는지를 다시 한번 더 점검한다. 상기 상태는, 예를 들어, 적재된 소포가 집배되었거나 그 소포를 집배하는 사람이 변경되었을 때에 변경된다. 유효화가 성공하면, 통신요청은 중앙송신요소(30)로 전송된다.

도3은 중앙송신요소(30)와 함께 처리 순서를 나타내는 구성도이다. 상기 중앙송신요소 내에 처리 흐름은 화살표로 나타냈다. 상기 중앙송신요소는 외부적으로 명령을 수신하고 통지를 전송하기 위한 목적을 위하여 연결된 데이터베이스로부터 필요한 데이터를 읽는다. 이들 데이터베이스는 적어도 클라이언트 데이터베이스(70), 소포 데이터베이스(80) 및 자동소포전달기계 데이터베이스(90)를 포함한다. 자동소포전달기계 데이터베이스는 시스템의 소포 컴파트먼트 유니트에 대한 데이터를 포함한다. 그 다음에, B2B 요소(20)가 지정한 템플릿(110)은 자료 데이터베이스(100)로부터 읽혀지고, 그 템플릿 내에 있는 플레이스홀더는 현재 데이터에 의하여 교체된다. 상기와 같은 방식으로 생성되는 전자우편 또는 SMS는, 예를 들어, 전자우편 또는 SMS 게이트웨이(120)를 통하여 송신될 수 있다.

도4는 통지 요소의 세부분을 조합하여 나타낸 구성도이다. 도면에 나타난 것과 같이, 오른쪽에 있는 중앙송신요소(30)와 왼쪽에 있는 비즈니스 로직 요소의 부분들 사이에는 확실하게 분리되어 있음을 알 수 있다.

본 발명에 따른 방법의 바람직한 실시예에 있는 기능들과 본 발명에 따른 시스템의 각 요소들에 대하여 상세하게 설명한다.

외부 인터페이스

외부 인터페이스(10)는 통지요소와 연결되고, 다양한 사용 경우들(Use Cases)로부터 직접적인 방식을 초래한다. 여기서, 각 경우에 대하여, 바람직하게는 그 자체의 기능은 통지 성부내에서 필수 기능성이 이루어질 수 있도록 정의된다. 이들 기능들은 물류시스템의 이벤트들에 대응하고, 예를 들어, 소포 객체들(parcel objects) 및/또는 사용자 객체들(user objects)과 관련된다. 물론, 상기 기능은 확장될 수 있고 다른 객체들과 관련될 수 있다.

newRecipient(User)

신규 클라인언트가 등록된 후에 호출된다.

updateRecipient(User)

클라이언트가 클라이언트 데이터베이스에 저장된 자신의 클라이언트 데이터를 변경한 후에 호출된다.

notifyDelivery(Parcel)

소정의 소포가 물류시스템의 자동소포전달 기계에 전달되어졌을때 호출된다.

motifyPickup(Parcel)

소정의 소포가 물류시스템에서의 자동소포전달기계으로부터 집배되었을때 호출된다.

parcelFailed(Parcel)

소정의 집배 기한전에 소포가 집배되지 않았기 때문에, 그 소포가 물류시스템의 자동소포전달기계로부터 되돌와 왔을때 호출된다.

addSubstitute(Parcel, User)

추가된 대체가 물류시스템의 자동소포전달기계에서 대기 소포에 대하여 추가되었을 때 호출된다.

removeSubstitute(Parcel, User)

소정의 대체가 물류시스템의 자동소포전달기계에서 대기 소포에 대하여 제거되었을때 호출된다.

해당하는 소포 개체 또는 사용자 객체는 각각 소정의 방법을 수신한다. 내부적으로 물류시스템의 이벤트는 통신요청 큐(40)에 임시로 저장되는 통지로 변환된다. 그 방법에 의하여 제공되는 결과는 그 변환과 임시 저장소가 기능을 했는지에 대하여 피드백을 수행한다.

템플릿 메카니즘

필요한 템플릿

다양한 형태의 통지들이 송신될 수 있고, 이에 대하여 템플릿(110)을 생성하고 생성된 템플릿들을 자료 데이터베이스에 저장하는 것이 유리하다고 증명되었다. 이와 같은 형태의 통지들은 템플릿 이름에 의하여 매핑되고, 그 템플릿 이름은 통지의 정보 내용의 레벨에 대하여 템플릿들을 분류한다. 예를 들어, B2B 경우에는, 다음과 같은 템플릿이 필요하다:

신규 클라이언트 등록 BNK1

클라이언트 데이터 변경 BNK2

소포 전달 BNK3, BNK3N

48시간 대기한 소포 BNK4, BNK4N

소포는 다음 시간 내에 되돌아올 것이다.

48시간내 BNK5, BNK5N

COD를 갖는 소포와 COD를 갖지 않는 소포대한 템플릿 변형들(variants)은 최후의 세가지 형태의 소포 통지를 위하여 이용될 수 있다. 이름 이외에, 템플릿도 DeliveryContract, 통신 형태 및 언어를 통하여 식별된다. 물론, 상기 서술된 템플릿이외에, 소정 수의 다른 템플릿들이 이용될 수 있다.

템플릿은 전자우편뿐만 아니라 SMS 의 폼으로 송신될 수 있는 모든 통지에 대하여 이용될 수 있어야만 한다. 전자우편에 의한 송신에 대하여, 바람직하게는 템플릿은 참조 라인에 대해서뿐만 아니라 메시지 텍스트에 대해서 이용되어야 한다.

데이터 저장

템플릿(110)의 관리를 간단히 하기 위하여, 템플릿들은 데이터베이스(100)에 저장된다. 본 발명의 바람직한 실시예에서, 상기 데이터베이스는 다음 [표 1]에 나타낸 것과 같이 여러 필드들을 포함한다.

필드	설명	형태	예
Contract	물류동업자 또는 물류 제공자 중에서, 그 전달계약의 식별번호(ID)	VARCHAR(16)	LC_4711,LP_4712,DC_4713
CommType	통신 형태	VARCHAR(12)	SMS, 평이한 텍스트 우편 헤더,이후에 옵션으로서 HTML 우편, 호출기, 팩스
Notification	통지의 형태,0절(section) 참조	VARCHAR(12)	BNK1, BNK2,BNK3, BNK3N,BNK4, BNK4N,BNK5, BNK5N,
Lang	언어	VARCHAR(5)	de-독일en-미국
Template text	저장된 템플릿 텍스트	VARCHAR(2048)

통지를 위한 물류시스템의 이벤트의 함수로서, 'Contract'라는 데이터베이스 키는 물류제공자(LogisticProvider) 또는 물류계약자(LogisticContractor)(BNK1 및 BNK2의 경우에) 또는 전달계약(DeliveryContract)(BNK3 ~ BNK5의 경우에)가 될 수 있다는 것을 당업자는 쉽게 알 수 있을 것이다.

플레이스홀더 메카니즘

구체적인 정보로 교체될 수 있는 템플릿(110) 내의 다양한 플레이스홀더를 이용하는 유리하다는 것이 증명되었다. HTML-포맷된 전자우편의 사용을 위하여(with an eye towards), 이들 플레이스홀더는 다음과 같은 HTML 태그처럼 편리하게 정의되어서는 안된다. 적어도 다음과 같은 플레이스홀더들이 제공되어져야 한다.

>M_NR< 물류시스템 클라이언트 수의 이벤트

>M_Address< 주소 형식

>M_FirstName< 이름

>M_SurName< 성

>M_SMS< 클라이언트의 SMS수

>M_Mail< 클라이언트의 전자우편 주소

>M_Street< 클라이언트의 거주 거리 및 집번지

>M_ZipCode< 클라이언트의 우편번호

>M_City< 클라이언트의 거주 도시 이름

>AUT_Street< 자동소포전달기계가 있는 거리 및 집번지

>AUT_ZipCode< 자동소포전달기계가 있는 우편번호

>AUT_City< 자동소포전달기계가 있는 도시이름

>POD_Amount< COD 금액과 유통화폐

상기 플레이스홀더이외에, 다른 플레이스홀더들도 사용될 수 있다.

메시지 길이

통상적으로 SMS 메시지의 최대 길이는 160문자(characters)이다. 물류시스템의 자동소포전달기계의 이벤트의 위치(location)와 같은 소정의 정보는 그 길이가 가변적이기 때문에, 상대적으로 지나치게 긴 필드(예를 들어, 도시 구역 정보를 갖는 거리명 또는 도시명의 경우)는 160문자의 '오버플로우'를 일으킨다. 이와 같은 '오버플로우'를 막기위하여, 본 발명의 실시예에서는 소정의 지능형 메카니즘(intelligent mechanism)이 이용된다. 즉, 각 필드의 중요성 및 이용 가능한 나머지 길이에 따라, 개별적인 필드 길이는 확장가능한 모든 기본적인 정보를 포함한다.

상기 지능형 메카니즘에 대안수단은, 160문자의 최대길이를 초과할 수 없도록, 적절한 데이터베이스에 모든 필드의 짧은 버전(short versions)의 저장소를 가지는 것이다. 그러나, 이는 SMS 템필릿의 변경은 새로운 길이의 제한을 수반하다는 점에서 단점이 있다. 따라서, 클라이언트가 입력하는 주소와 같은 소정의 정보는 쉽게 적용될 수 없다.

B2B 전달계약 로직(B2B DeliveryContract logic)

B2B 전달계약 로직(20)은 물류제공자(LogisticProvider), 물류계약자 (LogisticContractor) 및 전달계약 (DeliveryContract)(소정의 물류제공자와 소정의 물류계약자 사이의 계약)를 위한 개별 비즈니스 로직을 결정한다. 이와 같은 목적을 위하여, 개별 이벤트는 통지명령으로 변환된다. 물류시스템의 이벤트들(newRecipent와 updateRecipent)은 오직 LogisticProvider 또는 LogisticContractor에 종속적이고, 해당하는 사용자는 상기 LogisticProvider 또는 LogisticContractor과 연관된다. 물류시스템의 다른 이벤트들은 소포의 전달과 관련된다. 즉, 이들 이벤트들은 LogisticContractor(소포의 수신자 또는 전달자를 정의함)뿐만 아니라 LogisticProvider(소포를 운송함)에 종속적이다. 상기 로직을 구현하기 위하여, 송신된 통지 목록(통신요청)은 물류시스템의 각 이벤트를 위하여 정의된다. 이들 통신요청은 설정될 수 있는 여러 매개변수를 포함한다.

물류시스템의 이벤트

다중 통지(multiple notifications)는, 예를 들어, 반복된 통지가 이루어지거나 여러 다른 역할을 갖는 여러 사람들이 정보를 받는 경우에, 각 이벤트를 위하여 저장될 수 있다.

정보를 받은 사람들은 통지를 받는 사람들이다. 가능한 값들은 수신자(Recipient), 대체(Substitute), 물류제공자(LogisticProvider) 또는 물류계약자(LogisticContractor) 가 된다.

날짜는 통지가 송신되는 날에 대하여 지정된다. 로직에서, 오직 관련된 날짜가 저장되고, 그 다음에 그 저장된 날짜는 물류시스템의 이벤트의 날짜와 함께 계산되어 절대 날짜를 생성한다. 가능한 값들은 예를 들면 다음과 같다.

Immediately 통지는 즉시 송신된다

+X time units 통지는 X 타임 유니트에서 송신된다

-X time units 통지는 소포의 만료 전에 X 타임 유니트에서 송신된다.

통신의 형태는 지정될 수 있다. 예를 들어, 소정의 로직이 SMS에 의한 통지만을 허용하는 경우에, 그 지정과정은 필요하다. 가능한 값은 전자우편, SMS 및 사용자 (사용자를 위하여 지정된 통신 형태). 이와 같은 방식으로, 예를 들어, 전달 계약 로직은 매핑될 수 있고, 이는 지정한 통신 형태를 통하여 통지를 배타적으로 허용한다.

바람직하게는, 전송에 이용되는, 소정의 템플릿(110)을 선택할 가능성이 있다. 이는 다음과 같은 이점이 있다. 즉, 예를 들어, 물류시스템의 다른 이벤트에 대하여, 다른 텍스트는 같은 전달계약 내에서 이용될 수 있게 한다. 또한, 상기 템플릿은 현재 전달 계약(DeliveryContract)에 의하여 항상 더 제한된다. 따라서, 소정의 템플릿(예를 들어, BNK1)은 두 개의 다른 전달 계약(DeliveryContracts)를 위하여 다른 내용을 갖는다. 또한, 같은 템플릿의 다른 버전은 다른 형태의 통신에 이용될 수 있게 유지된다.

게다가, 추가 정보는 저장될 수 있고, 이는 비즈니스 로직 내에서 구별하는 데에 사용되거나 다음의 두 개의 가능한 정보와 같은 로직을 이후에 점검하는 데에 사용된다.

COD 소포의 구별

다른 템플릿은 COD 금액의 셋을 갖는 소포에 대하여 이용된다. 상기 템플릿은, 예를 들어, 소포를 집배하는 사람에 대한 정보로서, COD 금액을 포함한다.

B2B 처리단계가 있고, 그 단계 내에 COD 금액은 소포에 대하여 존재하지만, COD가, 예를 들어, 조합된 과금을 통하여 청구되기 때문에, 그 금액은 그 소포를 집배한 사람에게 전송되지 않는다.

소포가 집배되었는지 점검

이는 소포가 물류시스템의 자동소포전달기계에서 여전히 있는지 또는 소포가 소정의 시간 동안에 집배되었는지를 판단하기 위하여 실행되는 점검 동작이다. 촉구 통지가, 예를 들어, 며칠 후에 송신되는 경우에, 상기 동작은 상당히 유용하다.

소포 객체는 기한에 피드백을 제공하는 방법을 제공해야만 하고, 그 기한에 소포는 자동소포전달기계로부터 제거될 것이다. 이와 같은 과정은 기한 전에 통지 X날에 전송될 수 있도록 필요하다. 그 어떠한 기한 날짜도 설정되어 있지 않다면, 표준절차로서, 달력의 소정의 날들로 정해질 수 있다.

LogisticProvider DPAG (B2C 경우)

다음 표는 물류제공자를 위하여 사용자들이 등록한 시간에 송신될 통지(통신요청)을 정의하는 하나의 예이다. 이들은 전달자이고, 어떠한 통신도 송신되지 않는다.

물류시스템의 이벤트	정보를 받는 사람 (수신자, 교체, LP, LC)	날짜: 즉시, + X 날, - X 날 (만기전)	통신 형태(전자우편, SMS, 사용자)	템플릿	기타
신규 사용자	---	---	---	---
변경된 사용자	---	---	---	---

LogisticProvider DPAG (B2C 경우)

다음 표는 가상 물류계약자 ('최종 클라이언트')를 위하여 사용자들이 등록한 시간에 송신될 통지(통신요청)을 정의하는 하나의 예이다. 다음 표에서 B2C에 대하여 등록된 모든 사용자들은 컴파일 되어 있다.

물류시스템의 이벤트	정보를 받는 사람 (수신자, 교체, LP, LC)	날짜: 즉시, + X 날, - X 날 (만기전)	통신 형태(전자우편, SMS, 사용자)	템플릿	기타
신규 사용자	수신자	즉시	사용자	BNK1	밤에는 SMS 전송 안함
변경된 사용자	수신자	즉시	사용자	BNK2	밤에는 SMS 전송 안함

전달 계약 로직-> 최종 클라이언트 (B2C 경우)

다음 표는 물류 제공자와 최종 클라이언트 사이의 B2C를 위하여 전송될 통지(통신요청)를 정의하는 하나의 예이다.

물류시스템의 이벤트	정보를 받는 사람 (수신자, 교체, LP, LC)	날짜: 즉시, + X 날, - X 날 (만기전)	통신 형태(전자우편, SMS, 사용자)	템플릿	기타
전달된 소포	수신자	즉시	사용자	BNK3,BNK3N	COD 소포의 경우에 구분.소포가 선택되었는지 점검.밤에는 SMS 전송 안함
	수신자	+2일	사용자	BNK4,BNK4N	COD 소포의 경우에 구분.소포가 선택되었는지 점검.밤에는 SMS 전송 안함
	수신자	-2일	사용자	BNK5,BNK5N	COD 소포의 경우에 구분.소포가 선택되었는지 점검.밤에는 SMS 전송 안함
선택된 소포	---	---	---	---
전송된 소포	---	---	---	---
추가된 대체	---	---	---	---
제거된 대체	---	---	---	---

LogisticProvider LP (B2B 경우)

LogisticContractor LC (B2B 경우)

물류시스템의 이벤트	정보를 받는 사람 (수신자, 교체, LP, LC)	날짜: 즉시, + X 날, - X 날 (만기전)	통신 형태(전자우편, SMS, 사용자)	템플릿	기타
신규 사용자	수신자	즉시	사용자	BNK1	밤에도 SMS 전송
	공급자	즉시	사용자	???	밤에도 SMS 전송
변경된 사용자	수신자	즉시	사용자	BNK2	밤에도 SMS 전송
	공급자	즉시	사용자	???	밤에도 SMS 전송

DeliveryContract logic LP-> LC (기업간 경우)

물류시스템의 이벤트	정보를 받는 사람 (수신자, 교체, LP, LC)	날짜: 즉시, + X 날, - X 날 (만기전)	통신 형태(전자우편, SMS, 사용자)	템플릿	기타
전달된 소포	수신자	즉시	사용자	BNK3	소포가 선택되었는지 점검.밤에도 SMS 전송.
	수신자의 공급자	+4일	사용자	???	소포가 선택되었는지 점검.밤에도 SMS 전송.
선택된 소포	---	---	---	---
전송된 소포	---	---	---	---
추가된 대체	대체	즉시	사용자	BNK3	소포가 선택되었는지 점검.밤에도 SMS 전송.
제거된 대체	---	---	---	---

통신요청 큐 (CommunicationRequest queue)

전용 데이터베이스 표는 필요하고, 전송될 통지(통신요청)를 위한 명령은 그 전용 데이터베이스에 임시로 저장된다. 바람직하게는, 그 표는 큐를 관리만 한다. 소포와 수신자에 대한 구체적인 정보는, 예를 들어, 클라이언트 데이터베이스(70) 또는 소포 데이터베이스(80)로부터 항상 읽혀진다.

필드	설명	형태	예
전송을 실행하기 위하여 필요한 내부 필드들
RequestID	엔트리를 식별하는 명백한 키는 내부적으로 연속해서 생성된다.	NUMBER(16)RIMARYKEY
InsertDate	큐로 삽입되는 날짜는 내부적으로 생성된다.	DATE
CompletionDate	완전히 처리(상태=2)되거나 실패(상태=9)되는 날짜	DATE
RetryCount	이전 실패 시도 수	NUMBER(3)
State	요청 상태	NUMBER(3)	1=신규2=처리됨(완전히03=처리중(잠금)9=실패됨
외적으로 서술된 필드들, 이들은 B2B 요소에 의하여 제공됨
SendDate	날짜와 시간, 그 이후에는 전송되어야 함	DATE
RecipientID	수신자 식별번호(ID), 이는 사용자, 물류 제공자 또는 물류 계약자	VARCHAR(16)	LP_4711, LC_1234, US_0815
ParcelID	소포번호(공백이 될 수 있다)	VARCHAR(16)
Communication flags	전송을 제어하는 매개변수들은, 클이언틀 로직에서 형성된 결정은 이후의 질문의 경우에 재구성될 수 있도록 B2B 요소에 의하여 설정됨.	NUMBER(8)	CheckParcelInmachineDelaySMS Sending
외적으로 서술된 필드들, 이들은 사용된 템플릿을 식별한다.
Contract	물류동업자 또는 물류 제공자 중에서, 그 전달계약의 식별번호(ID)	VARCHAR(16)	LC_4711,LP_4712,DC_4713
CommType	통신 형태	VARCHAR(12)	SMS, 평이한 텍스트, 사용자(=사용자의 설정을 수행함), 이후에 선택적인 TMLMail, RFC1149, 호출기, 팩스
Notification	통지의 형태, 0절 참조	VARCHAR(12)	BNK1, BNK2,BNK3, 등
Lang	언어	VARCHAR(5)	de-독일en-미국, 사용자

그러나, 통신요청 큐의 필드를 확장하는 것이 유리할 수 있다. 예를 들어, 자동소포전달기계의 수와 자유로운 텍스트 설명이 추가될 수 있다. 이와 같은 방식으로, 통지는 소포와 연결될 수 있을 뿐만 아니라 우편번호, 이벤트 및 자동소포전달기계 수들의 조합과도 선택적으로 연결될 수 있다. 게다가, 동적으로 통지를 생성할 가능성이 있다.

'User'라는 값을 통하여 'Comm_Type' 엔트리와 함께, 통지가 사용자에 의하여 지정된 통신 형태를 통하여 이루어질 수 있다고 언급할 수 있다. 마찬가지로, 사용자의 설정이 이용된다면, 'User'라는 값과 'Lang'의 언어 설정을 위하여 입력될 수 있다. 하나의 엔트리(상태=3)의 로깅이 필요한 지 그렇지 않은지의 판단과 그와 같이 확대되는 판단은 구체적으로 구현되는 과정에 의존한다.

데이터베이스로 접근

물류시스템의 다음 데이터베이스에 접근하는 과정이 제공되어야만 한다.

* 클라이언트 데이터베이스: 이는 클라이언트의 수에 의하여 식별되는 클라이언트에 대한 정보를 제공한다.

* 물류제공자 데이터베이스: 이는 물류제공자에 대한 정보를 제공한다.

* 물류계약자 데이터베이스: 이는 물류계약자에 대한 정보를 제공한다.

* 전달계약 데이터베이스: 이는 물류계약자에 대한 정보를 제공한다.

* 소포 데이터베이스: 이는 명확한 소포 수에 의하여 식별되는 소포에 대한 정보를 제공한다.

* 자동소포전달기계 데이터베이스: 이는 자동소포전달기계 식별번호(ID)에 의하여 식별되는 자동소포전달기계의 위치(location)에 대한 정보를 제공한다.

통지 송신 순서

타이머

통지 요소는 통신큐(40)에서 모든 명령을 일정하게 점검한다. 이는 통지 요소 내에 있는 타이머(41)에 의하여 트리거된다. 바람직하게는 타이머 간격은 자유롭게 구성될 수 있다.

통신 큐 읽개 (communication queue reader)

타이머 함수가 호출되면, 모든 엔트리는 통신요청 큐(40)로부터 읽혀지고 그 엔트리의 송신날짜는 현재 날짜 이후가 된다.

Select * from communicaiton_request_queue

여기서, 상태+1 // 처리되지 않음

및 SendDate<now(); // 현재.

객체의 재구성

큐로부터 읽혀진 각 엔트리는 'CommunicationRequest'(통신요청) 객체로 변환된다. 정보를 받을 사용자에 대한 명확한 식별번호 (RecipientID)와 소포에 대한 식별번호(ParcelID)를 바탕으로, 해당하는 부분적인 객체는 재구성된다. 이는, 예를 들어, 전자우편 주소와 같은 객체의 현재 날짜를 질의(query)할 수 있도록 필요하다.

상기 경우에 'User'라는 용어는 'LogisticProvider' 객체 또는 'LogisticContractor' 객체 중에서 어느 하나를 참조한다. 상기 모든 객체는 'Notifiable'이라는 공유 인터페이스를 제공한다. 이는 관계된 객체에 통지를 송신하기 위한 방법을 제공한다. 예를 들어, 통지가 소포 전달, 예를 들어, 클라이언트 등록의 경우에 대하여 독립적으로 송신되는 경우에, 'Parcel'이라는 객체는 선택적으로 필요하지 않을 수 있다.

'Parcel'이라는 객체는, 차례대로, 소정의 방법을 제공하고, 그 방법에 의하여 소포가 위치한 자동소포전달기계가 접근될 수 있다.

객체의 독출 데이터(read-out data)는 제어 데이터(예를 들어, 전자우편 및/또는 SMS, 전자우편 주소)뿐만 아니라 전송된 데이터(예를 들어, 자동소포전달기계의 이름, 주소 및 위치)를 포함한다.

로직 점검

큐(40)로부터 읽혀진 통신요청은 통신요청이 여전히 유효한 통지인지를 판단하기 위하여 B2B 전달계약 로직(20)에 대하여 점점된다. 오직 단일 점검절차가 실행되면, 소포가 아직 집배되지 않았음을 확실하게 하기 위하여 소포 데이터베이스(80)로부터 출력된 데이터에 대하여 점검할 필요가 있다. 상기 소포가 소정의 시간 안에 집배된다면, 그 통지는 '종결'되었다고 고려된다. 이러한 목적을 위하여, 통신요청의 상태는 여전히 처리될 명령의 내부 큐로부터 제거된다 (상태는 '2'로설정되고, 이는 완전하게 처리됨을 의미함).

소포 데이터베이스(80)의 소포가 더 이상 존재하지 않으면, 그 시간 안에 집배가 되었음이 전제되고, 마찬가지로 통신요청은 처리되어야만 명령의 내부목록에서 제거된다.

중앙송신요소

통지는 중앙송신요소(30)로 전달된다. 통신요청에서 지시된 통신의 형태와 사용자의 설정을 바탕으로, 통신의 형태가 통지를 전달하기 위하여 이용되어야 하는 것이 확실하다. 여기서, 소정의 통신의 형태가 지정되지만 사용자가 그 형태의 통신을 지원하지 않는 경우에 오류가 발생한다.

오직 한 가지 통신 형태가 요구되면, 그 요구된 서비스 제공자 인터페이스(Service Provider Interface(SPI))가 직접적으로 호출된다. 사용자가 여러 통신 형태를 통하여 통지를 원하면, 그 통지가 제2형태의 통신이 아니라 제1형태의 통신을 통하여 성공적으로 수행된 경우에 대하여, 측정이 이루어져야 한다. 그 다음에, 제2형태의 통신은 제1형태의 통신을 다시 한번 사용하지 않고 반복적으로 시도되어야만 한다. 이러한 목적을 위하여, 각 원하는 형태의 통신에 대하여 'CommunicationRequest' 객체의 복사본을 발행하고 적당한 서비스 제공자 인터페이스(SPI)에 그 복사본이 전송되는 것이 중요하다.

개별 형태의 통신의 송신

개별 형태의 통신은 소위 서비스 제공자 인터페이스 (Service Provider Interfaces (SPI's))를 통하여 매핑된다. 각 각의 형태의 통신에 대하여 SPI가 있다. 각 SPI는 통신요청 객체와 함께 호출된다. 이와 같은 객체 내의 데이터의 함수로서, 전자우편 및/또는 SMS 가 생성된다. 이와 같은 목적을 위하여, 적절한 템플릿 (110)이 읽혀지고, 플레이스홀더는 적절한 데이터베이스로부터 읽혀진 정보에 의하여 교체된다.

송신 지연

통지 송신은 밤(예를 들어, 오후 10부터 새벽 6시까지)에 수행하는 처리는 전체적으로 또는 SMS 통지만을 제한하도록 하는 방식으로 구속될 수 있다. 전송에 대하여 완전히 중단되기를 희망하면, 이는, 예를 들어, 타이머에 의하여 달성될 수 있다. 그러나 전자우편은 방해를 일으키지 않기 때문에, 밤에는 SMS 통지의 전송만을 제한하는 것이 바람직하다. 이를 위하여, 그 전송은 SMS 서비스 제공자 인터페이스 내에서 중단되고, 송신 날짜는 허용 가능한 시간 대 (permissible window of time)에서 다음 적적한 시간 내에서 설정된다. 타이머가 상기 허용 가능한 시간 대 에 도달하는 최초의 경우에, 통신요청은 다시 읽혀지고 실행된다.

개연성 점검 (plausibility checks)

통지 성분은 전송된 데이터의 개연성 점검을 실행한다. 클라이언트는 클라이언트 데이터베이스(70)에서 빠져나와야만 하고, 소포는 그 소포 데이터베이스(80)로부터 빠져나와야 한다. 예를 들어, 클라이언트가 이이 삭제되었다면, 통지는 더 이상 송신되지 않는다. 게다가, 자동소포전달기계(위치)에 대한 정보는 존재해야만 한다. 수신자 주소(전자우편 또는 이동전화기 번호)가 잠재적으로 정확한 지 템플릿(110)의 모든 플레이스홀더가 데이터로 채워질 수 있는지가 점검된다. 게다가, 기존의 템플릿은 개연성을 가지고 있어야 한다. 템플릿 형태의 함수(차례대로, 이는 언어, 통신의 형태 및 B2B 로직에 대하여 변경됨)로서, 다음과 같이 중요한 데이터 필드는 템플릿에 존재해야만 한다.

템플릿	비고	템플릿에 있는 필요한 플레이스홀더
BNK1	신규 클라이언트	무
BNK2	변경된 클라이언트 데이터	무
BNK3, BNK4, BNK5	대기 소포	>AUT_Street<, >AUT_ZipCode<, AUT_City<
BNK3N, BNK4N, BNK5N	대기 COD 소포	>AUT_Street<, >AUT_ZipCode<, AUT_City<, >POD_Amount<

템플릿이 존재하지 않거나 그 템플릿이 적절한 엔트리를 가지고 있지 않으면, 그 송신은 단절되고 LOG 파일에서 적절한 오류 메시지가 생성된다. 템플릿은 점검되어야만 한다. 송신이 SMS에 의하여 실행되면, 지능형 메카니즘은 그 메시지를 160문자의 최대 길이에 맞게 고친다.

송신 실행

앞선 '템플릿 메카니즘' 절 (section)에서 설명된 것과 같이, 상기 메카니즘은 송신될 텍스트를 생성한다. 텍스트와 수신자 정보는 송신 형태의 함수로서 전자우편 또는 SMS 게이트웨이(120)로 전송된다. 상기 게이트웨이로 가는 전송이 실패하면, 제2전송은 간단한 오동작을 더 쉽게 극복할 수 있도록 즉시 시도될 수 있다.

결과 저장

전체 절차가 성공하면, 그 다음에 본 발명의 바람직한 실시예에서, 필드 상태가 '2'로 설정되는 방식으로, 그 엔트리는 진행 중인 명령의 큐에서 삭제된다. 동시에, 'CompletionDate' 필드는 '현재 날짜 + 시간'으로 설정된다. 통신요청 큐(40)에 있는 엔트리는 더 이상 처리되지 않는다. 통신요청 큐(40)에 있는 그 엔트리는 더 처리되지 않는다. 그 엔트리는 통지가 전달될 수 없는 가능성을 위하여 소정의 기간동안 상기 통신요청 큐에서 이용할 수 있도록 유리하게 남아 있어야만 한다.

여러 가지 이유로부터 오류가 발생할 수 있다.

* 클라이언트는 클라이언트 데이터베이스 (70)에 있지 않거나 자동소포전달기계는 자동소포전달기계 데이터베이스(90)에 있지 않다.

* 읽혀진 데이터는 개연성(plausible)이 없다 (예를 들어, 완전하게 채워지지 않음)

* 템플릿은 오류가 있거나 존재하지 않는다.

* 통지를 송신하는 것은 기술적인 이유로 인하여 가능하지 않다 (여러 시도후에)

소정의 오류가 발생하면, 'RetryCount' 필드가 증가된다. 'RetryCount'필드가 미리 결정된 값(이는 타이머의 주기에 종속적이다)을 초과하는 경우에, 오류 메시지는 로그(LOG) 파일에서 생성되고, 예를 들어, 수동적으로 재-처리가 시작된다. 예를 들어, 이는 통신요청 큐로부터 저장된 데이터를 점점하거나 엔트리를 수동적으로 삭제할 수 있다. 상기와 같은 오류 통지를 전달하기 위하여 끝없이 시도되는 것을 방지하기 위하여, 소정의 'RetryCount'필드가 가능한 한 빠른 시간 내에 도달하면 할수록, 상기 상태는 '9'로 설정된다. 이들 통지는 처리되지 않는다. 게다가, 현재 날짜는 중단의 날짜(date of interruption)로서 'CompletionDate' 필드에 저장된다. 오류를 삭제한 후에, 상태는 수동적으로 다시 '1'로 설정되어야만 한다. 마찬가지로, 'CompletionDate'필드와 'RetryCount'필드는 재설정되어야만 한다.

규칙적인 삭제 (regular clean-up)

통신요청 큐를 규칙적으로 '삭제'할 필요가 있다. 소정의 기간보다 더 시간(예를 들어, 일주일)동안에 마무리된 모든 완전한 경우들은 데이터베이스로부터 제거되야 한다. 게다가, 한 달이 더 지난 모든 오류의 경우는 통신요청 큐에서 삭제되어야 한다. 완료 또는 중단 날짜는 'Completiondate' 필드에 저장된다. 예를 들어, 다음이 실행된다.

Delete from communication_queue

여기서 상태=1 및 completion_date<현재+7일

또는 상태=9 및 completion_date<현재+30일.

로깅 메카니즘

송신 전자우편 또는 SMS에 있는 오류는 오류 로그 파일(error LOG file)에 로깅된다. 이들 LOG 파일은, 예를 들어, 게이트웨이의 실패를 확실하게 나타낼 수 있도록 규칙적으로 감시되어야 한다. 또한, 적어도 최초의 단계에서, 모든 송신된 통지는 로깅되어야 한다. 이를 위하여, 전용 LOG 파일은 오류 감시를 간단하게 하기 위하여 이용된다.

디자인 제안 및 구속

타이머의 구현을 위하여 여러 대안들이 있다. 즉, 다음에 나열하는 요소들을 통하여 구현될 수 있다.

- 애플리케이션이 내부 타이머를 통하여

- 크론(cron) 작업을 통하여

- 데이터베이스 타이머를 통하여

- 다르게 개발된 솔루션을 통하여

환경설정(preference)은 제1의 변형예를 가능하게 한다. 전자우편 절차와 SMS 송신절차를 실행하기 위하여 여러 가능한 대안들이 있다.

- JMAPI (Java Message API)

- JMS

- 애플리케이션 서버에서 적절한 전자우편 서비스의 활용

여기서, 제1의 두 개의 변형예가 선택될 수 있다.

설계

통지 요소는 일반우편 또는 인터넷 페이지를 포함할 필요가 없다. 그러나 다른 템플릿들은 개별 통지를 위하여 필요하다. 템플릿이 즉각적으로 교환될 수 있게 하는 것이 유리하다. 다음 절(sections)에 설명되는 템플릿들은 단순히 예를 보이기 위한 실시예에 불과하다. 물론 다른 원하는 통지 텍스트는 적절한 플레이스홀더와 통합될 수 있다.

BNK1=등록 확인

전자우편에 의한 통지

포장 스테이션에 오신 것을 환영합니다.

안녕하세요 >M_Address< >M_Surname<귀하가 포장스테이션에 등록한 정보는 다음과 같습니다: >M_Address< >M_Firatname< >M_Surname< >M_Street< >M_ZipCode< >M_City< 전자우편: >M_Mail< SMS: >M_SMS<귀하의 회원번호는 >M_NR< 입니다.

SMS에 의한 통지

포장 스테이션에 오신 것을 환영합니다. 귀하의 회원번호는 >M_NR< 입니다.

BNK2=클라이언트 데이터에서 변경 확인

전자우편에 의한 통지

포장 스테이션에서 귀하의 주소 데이터 변경

안녕하세요 >M_Address< >M_Surname<귀하가 포장스테이션에 저장한 정보는 다음과 같이 변경되었습니다: >M_Address< >M_Firatname< >M_Surname< >M_Street< >M_ZipCode< >M_City< 전자우편: >M_Mail< SMS: >M_SMS<귀하의 회원번호는 >M_NR< 입니다.

SMS에 의한 통지

안녕하세요>M_Address< >M_Firatname< >M_Surname<. 귀하가 저장한 포장 스테이션 데이터는 다음과 같이 변경되었습니다: >M_Street< >M_ZipCode< >M_City<

BNK3='신규 소포'통지

전자우편에 의한 통지

귀하에게 신규 포장 스테이션 소포가 도착했습니다.

안녕하세요 >M_Address< >M_Surname<귀하의 신규 소포가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<귀하는 소포를 집배하기 위하여 7일이 남아 있습니다. 귀하의 클라이언트와 귀하의 PIN이 있음을 기억하십시오.

SMS에 의한 통지

안녕하세요>M_Address< >M_Firatname< >M_Surname<. 귀하의 신규 소포가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<

BNK3N='COD를 갖는 신규 소포'통지

전자우편에 의한 통지

귀하에게 신규 포장 스테이션 COD 소포가 도착해 있습니다.안녕하세요 >M_Address< >M_Surname<.귀하의 신규 COD 소포가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.귀하는 소포를 집배하기 위하여 7일이 남아 있습니다. 귀하의 클라이언트 카드와 귀하의 PIN를 가져오시는 것을 잊지 마십시오. COD 금액은 >POD_amount<입니다. 귀하는 EC카드 또는 현금카드로 지불할 수 있습니다.

SMS에 의한 통지

안녕하세요>M_Address< >M_Surname<. 귀하의 신규 COD 소포 (>POD_amount<)가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< >AUT_ZipCode < >AUT_City<.

BNK4N='48시간동안 대기한 소포'통지

전자우편에 의한 통지

귀하의 포장 스테이션 COD 소포가 48동안 대기하고 있습니다.안녕하세요 >M_Address< >M_Surname<.귀하께 상기시켜드립니다: 귀하의 소포가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.귀하는 소포를 집배하기 위하여 5일이 남아 있습니다. 귀하의 클라이언트 카드와 귀하의 PIN을 가져오시는 것을 잊지 마십시오.

SMS에 의한 통지

안녕하세요>M_Address< >M_Surname<. 귀하의 소포 (>POD_amount<)가 포장 스테이션 자동소포전달기계에 48시간동안 대기하고 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.

BNK4N='POD를 갖는 소포가 48시간동안 대기하고 있음'통지

전자우편에 의한 통지

귀하의 포장 스테이션 COD 소포가 48동안 대기하고 있습니다.안녕하세요 >M_Address< >M_Surname<.귀하께 상기시켜드립니다: 귀하의 소포가 포장 스테이션 자동소포전달기계에 도착해 있습니다 >AUT_Street< ><AUT_ZipCode< >AUT_City<.귀하는 소포를 집배하기 위하여 5일이 남아 있습니다. 귀하의 클라이언트 카드와 귀하의 PIN을 가져오시는 것을 잊지 마십시오. COD 금액은 >POD_amount< 입니다. 귀하는 EC카드 또는 현금카드로 지불할 수 있습니다.

SMS에 의한 통지

안녕하세요>M_Address< >M_Surname<. 귀하의 COD 소포 (>POD_amount<)가 포장 스테이션 자동소포전달기계에서 48시간동안 대기하고 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.

BNK5N='소포는 48시간 내에 제거될 것임'통지

전자우편에 의한 통지

귀하에게 포장 스테이션 소포가 도착해 있습니다.

안녕하세요 >M_Address< >M_Surname<.시간이 거의 되었습니다: 귀하의 소포가 포장 스테이션 자동소포전달기계에서 대기하고 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.귀하가 패키지를 집배해 가지 않으면 전달할 수 없다는 이유로 그 소하물은 48시간내에 되돌아 송신될 것입니다. 귀하의 클라이언트 카드와 귀하의 PIN을 가져오시는 것을 잊지 마십시오.

SMS에 의한 통지

안녕하세요>M_Address< >M_Surname<. >AUT_Street< >AUT_ZipCode< >AUT_City< 의 포장 스테이션 자동소포전달기계에 있는 귀하의 소포는 48시간 내에 다시 송신될 것입니다.

BNK5N='POD 소포는 48시간 내에 제거될 것임'통지

전자우편에 의한 통지

귀하의 포장 스테이션 COD 소포가 대기하고 있습니다.안녕하세요 >M_Address< >M_Surname<.시간이 거의 되었습니다: 귀하의 COD 소포가 포장 스테이션 자동소포전달기계에서 대기하고 있습니다 >AUT_Street< >AUT_ZipCode< >AUT_City<.귀하가 패키지를 집배해 가지 않으면 전달할 수 없다는 이유로 그 패키지는 48시간내에 되돌아 송신될 것입니다. 귀하의 클라이언트 카드와 귀하의 PIN을 가져오시는 것을 잊지 마십시오. COD 금액은 >POD_amount< 입니다. 귀하는 EC카드 또는 현금카드로 지불할 수 있습니다.

SMS에 의한 통지

안녕하세요>M_Address< >M_Surname<. >AUT_Street< >AUT_ZipCode< >AUT_City< 의 포장 스테이션 자동소포전달기계에 있는 귀하의 COD 소포(>POD_amount<)는 48시간 내에 다시 송신될 것입니다.

다른 요소들의 필요조건

'Parcel'(소포)라는 객체

'Parcel'객체는 명확한 소포 번호에 의하여 식별되는 소포에 대한 정보를 제공해야만 한다:

* 'Parcel' 객체는 기한 날짜에 피드백(feedback)을 제공하는 방법을 제공해야만 하고, 그 기한 날짜에 그 소포는 자동소포전달기계에서 제거될 것이다. 이는 기한 전에 통지 X날을 전송하기 위하여 필요하다. 어떠한 기한날짜도 설정되어 있지 않으면, 표준 절차, 소정의 달력의 일수 (예를 들어, 9일)가 전제될 수 있다.

* 'DeliveryContract'(전달계약) 객체는 소정의 방법을 통하여 전달되어야만 한다.

* 'Parcel' 객체는 소포가 위치한 자동소포전달기계에 접근하는 방법을 제공한다.

'Machine'(기계)라는 객체

'Machine'객체는 자동소포전달기계 데이터베이스 (90)에 접근하게 하고, 이는 자동소포전달기계 식별번호(ID)에 의하여 식별된다.

* 상기 객체에 있는 방법은 자동소포전달기계의 위치에 대한 정보를 제공해야만 한다.

통지될 객체 (통지할 수 있는 객체): 사용자, 물류제공자 및 물류계약자

'사용자'라른 객체는 클라이언트에 의하여 식별되는 클라이언트에 대한 정보를 제공한다. '물류제공자'라는 객체는 물류제공자 데이터베이스에 접근하게 한다. '물류계약자'라는 객체는 물류 계약자에 대한 정보를 제공한다.

* 모든 객체들은 'Notifiable'이라는 공유 인터페이스를 구현한다. 이는, 예를 들어, 전자우편 주소 또는 주소 형태를 읽기 위하여, 관련된 객체에게 소정의 통지를 송신하기 위한 필요한 방법을 제공한다.

* 명확한 식별번호(ID)에 의하여 'Notifiable' 객체를 식별할 수 있어야만 한다. 이를 위하여, 'User'의 식별번호(ID), 'LogisticProvider' 객체 및 'LogisticContractor' 객체는 'getUniqueID'라는 방법을 통하여 되돌려 줄 수 있다. 여기서, 'User'의 식별번호(ID), 'LogisticProvider' 객체 및 'LogisticContractor' 객체는 객체 형태 (US_, LP_, LC_)의 식별로 연결된다. 상기 방법은 'Notifiable'이라는 인터페이스에서 유리하게 정의될 수 있어야 한다.

* 상기 식별번호(ID)에 의하여 'Notifiable'객체를 재구성하기 위하여, 객체 제작소는 구현되고, 이는 상기 식별번호(ID)를 바탕으로 적절한 객체를 생성한다.

로직 객체: 전달계약, 물류제공자 및 물류계약자

* B2B 로직은 모든 객체들, 예를 들어, 공유 인터페이스를 통하여 질의(query)되어야 한다.

* 상기 객체는 명확한 식별번호(ID)에 통하여 식별될 수 있어야 한다. 이를 위하여, 'Notifiable' 이라는 객체의 식별번호 (getUniqueID)는 사용될 수 있고, 이는 'LogisticProvider' 와 ' LogisticContractor'에 대하여 이미 존재한다. 또한, 해당하는 방법은 'DeliveryContract'에 존재해야만 하고, 이는 객체의 식별번호(ID)에 피드백을 제공한다. 상기 'DeliveryContract'는 객체 형태의 식별(DC_)로 연결된다.

본 발명에 따른 절차를 더 개선하기 위하여, 다음 측정을 개별적으로 또는 함께 실행하는 것이 유리할 수 있다.

* 모든 전자우편은 통신요청 큐로 쓰여지고 그 통신요청 큐로부터 일정한 간격으로 독출되고 처리된다는 점에서 상기 전자우편은 오프라인으로 송신된다.

* 구현은 소정(그러나 바람직하게는 고정되어야 함)의 언어를 지원할 수 있다.

* 바람직하게는, 전자우편은 평이한 텍스트(plain text)로 송신된다.

그러나 본 발명에 따른 바람직한 실시예는 다음 항목들에 대하여 더 개선할 수 있다.

* HTML로 포맷된 전자우편의 지원

* 여기서, 등록 시점에, 클라이언트는 그가 전자우편(PlainText 또는 HTML)을 수신할 포맷을 선택할 수 있다. 따라서 다른 템플릿은 송신절차 동안에 이용될 수 있다.

* 다중 언어 수용 능력

클라이언트는 등록시점에 그의 바람직한 언어를 지정할 수 있다. 따라서 다른 템플릿은 송신 절차동안에 이용될 수 있다.

* RFC1149 표준을 통하여 통지의 지원

* 또한 내용 관리 시스템(Content Management System)은 전자우편 또는 SMS를 위한 템플릿을 더 쉽게 관리하게 한다.

Claims

물류시스템 사용자에게 통지를 전송하는 방법에 있어서,

상기 물류시스템 내에서 서로 다른 이벤트들에 따라, 관련된 함수들을 갖는 다른 모듈들이 각각의 경우에 호출되고, 그럼으로써 상기 모듈들은 중앙송신요소(30)로 전송되는 통지명령을 생성하고, 그 통지명령을 바탕으로, 상기 중앙송신요소(30)는 적절한 통지들을 생성하여 상기 사용자에게 전송하는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제1항에 있어서, 상기 물류시스템은 하나 또는 그 이상의 등록된 사용자와 함께 하나 또는 그 이상의 소포 컴파트먼트 시스템(parcel compartment systems)을 동작시키는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제1항 또는 제2항에 있어서, 상기 중앙송신요소(30)는 통지를 생성하기 위하여 하나 또는 그 이상의 데이터베이스에 접근하는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제3항에 있어서, 상기 중앙송신요소(30)은 적어도 클라이언트 데이터베이스(70), 소포 데이터베이스(80), 자동소포전달기계 데이터베이스(90) 및 자료 데이터베이스(100)에 접근하는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제4항에 있어서, 상기 클라이언트 데이터, 상기 소포 데이터 및 상기 소포 컴파트먼트 시스템 데이터는 식별번호(ID)를 이용하여 상기 데이터베이스들에 할당되는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제2항 내지 제5항 중에 어느 한 항에 있어서, 상기 이벤트들은 적어도 다음 사항들을 포함하는 것을 특징으로 하고, 상기 다음 사항들은

- 신규 사용자 등록하는 단계

- 사용자 데이터 변경하는 단계

- 소정의 소포 컴파트먼트 시스템에 신규 소포의 위치시키는 단계

- 소포 컴파트먼트 시스템으로부터 소정의 소포 집배(picking-up)하는 단계

- 소정의 소포를 되돌려 보내는 단계

- 소정의 소포를 집배하기 위한 대체(substitute)를 추가하는 단계

- 소정의 대체를 제거하는 단계를 포함하는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
상기 선행하는 청구항 중에 어느 한 항에 있어서, 상기 모듈들에 의하여 생성된 통지명령들은, 상기 통지들이 즉시 전송될 수 있도록 상기 중앙송신요소(30)에 전달되거나 상기 통지들이 연기되는 전달 방식으로 전송될 수 있도록 상기 통지들이 통신요청 큐(40)에 저장되는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제7항에 있어서, 상기 통지 명령들은 타이머-제어 방식으로 소정의 큐 읽개(50)를 이용하여 통신요청큐(CommunicationRequestQueue)(40)로부터 읽혀져서 상기 중앙송신요소(30)로 전송되고, 상기 중앙송신요소(30)는 적절한 사용자-특정 통지들을 생성하여 소정의 게이트웨이(120)를 통하여 상기 사용자들에게 전송하는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
제8항에 있어서, 상기 통지들이 상기 중앙송신요소(30)로 전송되기 전에, 상기 통지 명령들의 상태는 전달계약(DeliveryContract) 로직(60)에서 유효화게 되는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
선행하는 청구항 중에서 어느 한 항에 있어서, 상기 통지들은 전자우편 및/또는 SMS 폼(form)으로 상기 사용자들에게 전송되는 것을 특징으로 하는 물류시스템 사용자에게 통지를 전송하는 방법.
물류 시스템 내에서 사용자에게 통지들을 전송하는 시스템에 있어서, 상기 제1 내지 제10항 중에 어느 한 항에서 서술되는 방법을 실행할 수 있는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제10항에 있어서, 적어도, 통지 명령을 생성하는 함수를 각각 가지는 모듈들, 중앙송신요소(30), 통신요청 큐(40) 및 하나 또는 그 이상의 데이터베이스를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제12항에 있어서, 특정한 사용자들에 대하여 개별 통지를 생성하는 템플릿(110)을 가지는 자료 데이터베이스(100)를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제11항 내지 제13항 중에 어느 한 항에 있어서, 클라이언트에 대한 정보를 가지는 클라이언트 데이터베이스(70)를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제11항 내지 제14항 중에 어느 한 항에 있어서, 소포에 대한 정보를 가지는 소포 데이터베이스(80)를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제11항 내지 제15항 중에 어느 한 항에 있어서, 자동 소포 컴파트먼트 시스템에 대한 정보를 가지는 자동소포전달기계 데이터베이스(90)를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.
제11항 내지 제16항 중에 어느 한 항에 있어서, 상기 통지를 송신하기 위한 게이트웨이(120)를 포함하는 것을 특징으로 하는 사용자에게 통지들을 전송하는 시스템.