KR20050027134A - 다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템 - Google Patents

다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템 Download PDF

Info

Publication number
KR20050027134A
KR20050027134A KR1020057001585A KR20057001585A KR20050027134A KR 20050027134 A KR20050027134 A KR 20050027134A KR 1020057001585 A KR1020057001585 A KR 1020057001585A KR 20057001585 A KR20057001585 A KR 20057001585A KR 20050027134 A KR20050027134 A KR 20050027134A
Authority
KR
South Korea
Prior art keywords
recipient
data
transmission
computer program
delivery
Prior art date
Application number
KR1020057001585A
Other languages
English (en)
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 트레이드 윈드 커뮤니케이션스 리미티드
Publication of KR20050027134A publication Critical patent/KR20050027134A/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/163—Interprocessor communication
    • 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/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/563—Data redirection of data network streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/24—Negotiation of communication capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Data Mining & Analysis (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Document Processing Apparatus (AREA)

Abstract

본 발명은 다중 전달 매체를 통하여 수신자에게 정보를 전달하기 위한 벌크통신 방법 (100), 벌크 통신 시스템, 벌크통신용 컴퓨터 프로그램에 관한 것이다. 매체는 팩시밀리, 전자우편, 일반우편, 단문(SMS) 메시지 전송 및 저장소(archiving)를 포함한다 (미래에 나타날 새로운 형태의 매체 포함). 단일 인터페이스는 하나 이상의 자료(110) 및 각 수신자에게 특정한 데이터(106)를 포함하여 분배하기 위한 정보(106, 108, 110)를 수신하는 데에 이용된다. 수신된 정보(106, 108, 110)를 바탕으로 하는 최소한 하나의 자료는, 수신자의 전달 선호(112, 176)를 바탕으로 각 수신자에게 지정한 전달 매체(144, 150, 156, 162, 168)를 이용하여 전송된다. 자료의 점차적 증대(172, 178)는 지정된 전달 매체에 의한 전송이 이루어지지 않은 수신자에 대하여 다른 전달 매체를 이용함으로써 생성된다. 점증적 증가 단계(172, 178)는 각 수신자에 대한 자료의 전달에 대하여 캐리어로부터 상태정보(176)에 종속적이다.

Description

다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템 {A BULK COMMUNICATIONS PROCESS USING MULTIPLE DELIVERY MEDIA}
본 발명은 벌크 통신에 관한 것으로서 특허 다중 전달 매체를 이용한 벌크 통신 방법 및 그 시스템에 관한 것이다.
[관련 출원]
본 출원은 트레이드 윈드 커뮤니케이션스 리미티드(Trade Wind Communications Ltd.) 명의로 2002년 7월 29일에 출원한 호주 가출원 제2002950435호의 우선권을 주장한 출원으로서, 그 내용은 본 출원에서 인용한다.
법인 (business), 회사 및 기관 (앞으로 단순하게 '발신자(originators)'라고 부르기로 함)은 고객, 공급자 및 다른 관련자 (앞으로 단순하게 '수신자(recipients)'라고 부르기로 함)와 여러 이유 때문에 벌크 통신을 이용한다. 일반적으로 이와 같은 벌크통신은 수신자로 전송되는 일반우편, 전자우편, 팩스 및 수신자의 이동전화로 전송되는 단문 메시지 서비스 (SMS)와 같은 매체 중에 어느 하나를 이용하여 이루어진다.
발신자는 수신자에게 일반적인 마케팅 통신문을 전달하는 것으로부터 청구서, 계산서 또는 독촉장과 같은 필수적인 정보를 반복해서 전달하는 것에 이르기까지 여러 다른 형태의 벌크 통신을 수행한다. 일반적으로, 이와 같은 벌크통신은 다음과 같은 공통적인 요소들을 갖는다.
* 수신자 정보의 목록은 때때로 병합된 데이터베이스 또는 회계 시스템으로부터 추출되는 것을 요구하면서 분리되게 제공된다.
* 템플릿 자료의 폼이 이용된다.
* 수신자 목록의 데이터는 상기 템플릿 자료에 병합, 즉 덮어 쓰여진다.
* 최종 "병합된" 자료는 고객에게 전달된다.
수신자에 대한 통신은 발신자의 다른 부서 또는 엔터티로부터 시작될 수 있고 사용되고 있는 통신매체의 형태에 종속적인 다른 방법으로 실행될 수도 있다. 발신자가 일반우편, 전자우편, 팩시밀리 또는 단문 메시지 서비스를 통하여 정보를 전송하는 것에 종속적인 다른 인터페이스와 그 기술을 이용하여, 발신자는 여러가지 통신을 실행한다. 발신자가 사내에서 관련된 통신에 대하여 필요한 약간의 기술 또는 모든 기술을 호스팅할 수 있으나, 경우에 따라 그 통신을 하청할 수도 있다.
우편 병합 소프트웨어 애플리케이션은 편지봉투에 주소 스티커를 생성하고 편지를 병합하여 인쇄하는 일을 한다. 또한 발신자는 일반우편 병합을 관리하기 위하여 사내에 설치된 독점적인 (proprietary)시스템과 인쇄 부서를 갖는다. 우편 집배소(mailing houses)에는 발신자에게 일반우편 필요조건을 하청할 능력을 제공한다. 일반적으로 맞춤형 스크립트는 발신자의 데이터베이스로부터 추출된 데이터를 지도표로 작성하고 미리 인쇄된 종이(paper stock) 위에 그 추출된 데이터를 겹쳐서 기재되게 한다.
팩시밀리(팩스) 기기는 목록을 저장하여 벌크 메시지 전송을 수행할 수 있다. 통신할 데이터의 크기에 따라, 마이크로 소프트 아웃룩과 같은 툴(tool)을 이용함으로써, 벌크 전자우편이 수행될 수 있다. 이와 같은 애플리케이션은 사용자가 데이터 저장소의 데이터 필드를 MS 워드 자료로 병합하게 하고, 우편 병합 툴을 통하여 전자우편 방식으로 수신자 목록으로 그 병합된 자료를 전송한다. MS 아웃룩과 MS 워드 뿐만아니라 다른 소프트웨어 응용프로그램도 상기와 같은 비슷한 기능을 갖는다. 이와 같은 분야에서 소프트웨어 솔루션을 위하여, 팩스 카드 및 팩스 입력 드라이버 등은 네트워크 또는 그 소프트웨어가 설치된 워크스테이션에 설치되어야 한다. 법인 또는 회사도 벌크 팩스 서비스와 벌크 전자우편 서비스를 제공한다. 일부는 발신자가 제공하는, 다른 수신자를 위한 개인적인 자료를 요구하고; 다른 일부는 발신자를 위한 데이터의 병합을 실행한다. 전사적 자원 관리(Enterprise Resource Planning(ERP))와 회계 소프트웨어 (accounting software)는 애플리케이션 또는 소프트웨어 패키지가 전자우편 또는 팩스를 수용할 능력을 갖도록 지원한다. 그러나 상기와 같은 지원하는 사항은 벌크 개인화(bulk personalisation)와 벌크 전달을 허용하기 보다는 오히려, 통상적으로 개인적인 통신 (즉, 단일 전자우편 또는 팩스를 사업처리 과정의 임의의 지점에서 팩키지 내로부터 전송하는 통신)에 적합하다.
발신자는 그들의 시스템들이 캐리어를 통하여 SMS 메시지를 발송하기에 적합하게 할 수 있다. 통상적으로, 이는 "전자우편으로부터 SMS로" 형태의 서비스를 이용하여 이루어지고, 그 서비스는 전자우편이 미리 결정된 방식으로 포맷된, 특정 주소로 전송되게 하고, 그 다음에는 SMS 메시지로서 이동전화기로 전송되게 한다. 발신자는 SMS 메시지 전송을 벌크 아웃소싱으로 이루어지게 하거나, 다른 전달 메카니즘과 동일한 종류의 데이터베이스로부터 개인화 데이터를 병합하는 수용 능력(capability)을 갖는 제3의 제품에 의한 프로비젼(provision) 지원한다. 그러나 상기 발신자는 일반적으로 상기와 같은 벌크 아웃소싱에 대한 수용 능력을 제공하지는 않는다.
통상적으로, 제한되고 조합된 서비스는, 전자우편을 팩스 또는 SMS로 전송할 수 있게 한다. 다른 전송 방법들 중에서, 이들 서비스는 포맷과정을 제공하지 않고 기능성을 병합하지 않는다. 이와 같은 서비스는, 같은 수신자 목록과 데이터베이스를 이용하는 동안에 특정한 포맷과정 규칙이 다른 전달 메카니즘에 대하여 서술되는 것을 허용하지 않고, 전달 선택사항들 중에서 어느 하나로서 일반우편을 지원하지 않는다.
(ACI로부터) MesssginDirect는 e-Courier를 제공한다. E-Courier 1은 직접 전자 청구 및 결재 솔루션을 나타낸다. 이와 같은 툴(tools)은, 전통적인 직접 기업-대-기업 간의 서류 거래 방법을 전자적인 전달 방법(electronic delivery)의 속도, 효율 및 융통성과 조합시키려고 한 솔루션이다. 또한 상기 두 가지는 직접 e-기업을 통하여 스트림라인 기업 처리(streamlined business process)를 수월하게 이용하기 위한 시도를 한다. 여기서, e-기업은 디지털 서명, 법적인 구속 및 보안적으로 전달된 엔드-대-엔드 e-거래와 관련되고, 엔드-대-엔드는 청구서, 계산서, 구매서, 확인서 및 정책을 포함한다. 전체적인 기업 처리는 기업과 그들의 고객 사이 및 동업자와 제공자 사이에서 직접적으로 전자 채널을 통하여 온라인으로 e-거래가 이루어 질 수 있게 한다. 메시징디렉트(MessagingDirect) 시스템은 전자우편, 팩스 또는 일반우편의 전달을 위하여 통합된 인터페이스를 지원하지 않는다. 메시징디렉트(MessagingDirect) 제품은 모든 수신자가 그 서비스를 등록할 것을 요구한다.
(Xpedite으로부터) 메시지리치(MessageReach)와 팩스 메일머지(Fax MailMERGE)은 다른 매체에 대하여 다른 서비스 (offerings)을 제공하지만, 동시에 개인화를 하지 않고 다중 매체에게 단일 수신자 목록을 전달한다.
펄스 엔터프라이즈 (에스커 소프트웨어(Esker Software) 제공)는 다른 비슷한 애플리케이션이지만 점증적 증대를 합병하지 않고, ASP 모델로서 (또는 웹서비스로서)제공되지 않으며, 일반우편 전달을 지원하지 않는다. 펄스 엔터프라이즈 애플리케이션도 상기 소프트웨어와 함께 설치될 수 있도록 팩스 카드 등을 필요로 한다. 펄스 엔터프라이즈 애클리케이션을 이용하는 회사는 그들의 환경에 맞게 소프트웨어 및 하드웨어를 설치해야 하고, 팩스, SMS, 전자우편 인터페이스 등 뿐만 아니라 펄스 엔터프라이즈 애플리케이션을 관리해야 한다. 펄스 엔터프라이즈 애플리케이션은 제너럴 도큐먼트 레코그니션(General Document RecognitionTM (GDR)) 성분(component)을 포함한다. 제너럴 도큐먼트 레코그니션(General Document RecognitionTM (GDR))은, 텍스트와 프린트-스트림 데이터를 다중 전자 포맷으로 변환하고, 이들 자료를 처리하여 및 수신기기에 그 처리된 자료를 전달하는 과정들을 자동적으로 처리하려고 한다.
따라서 발신자가 단일 통신 인터페이스를 갖는 하나의 벌크 통신 서비스를 이용하게 할 수 있고, 수신자 데이터와 동일한 데이터 셋(the same set of recipet data)을 다시 이용할 수 있게 하는 자동화된 서비스가 확실하게 있어야 하고, 그래서 수신자에 대한 벌크 통신이, 종래의 또는 일반 우편, 전자우편, 팩스 및 SMS ( 및 미래에 있을 다른 새로운 전달 매체)를 포함하는, 모든 기존의 다른 매체를 통하여 실행될 수 있게 한다. 또한 발신자가 제1매체를 통하여 정보가 전달되지 못했을 경우 그 정보가 전달 될 수 있는 방법을 포함하는 정보를 수신하기 위한 각 수신자의 선호를 바탕으로 수신자에 대한 메시지 전달을 관리할 수 있게 하는 자동화된 서비스가 확실하게 있어야 한다. 이는 발신자는 특정한 전달 형태를 지정하는 기술을 설치하여 관리할 필요가 없다. 또한, 수신자의 선호를 바탕으로, 전체 전달 매체(팩스, 전자우편, SMS, 서신 및 저장소(archiving))에 대한 단일 인터페이스를 통하여 데이터를 포맷하고 전달할 수 있는 자동화된 서비스가 필요하다.
도1은 본 발명의 실시예에 따른, 메시지를 다루는 과정을 나타낸 순서도이다.
도2는 본 발명의 실시예에 따른, 세 가지의 다른 접근 방법을 위한 서비스 인터페이스를 나타낸 구성도이다.
도3은 본 발명의 실시예에 따른, 꽂을 수 있는 데이터 파일 변환기(pluggable data file converter)를 나타낸 구성도이다.
도4는 본 발명의 실시예에 따른 자료 병합기를 나타낸 구성도이다.
도5는 본 발명의 실시예에 따라, 수신자에 대한 선호 규칙과 각 수신자에 대한 해당하는 전달 매체를 다루는 과정을 나타낸 순서도이다.
도6은 본 발명의 실시예에 따라, 수신자 선호를 바탕으로 점증적 처리과정에 대한 처리를 나타낸 순서도이다.
도7은 본 발명의 실시예에 따라, 통합된 보고를 생성하기 위한 처리를 나타낸 순서도이다.
도8은 본 발명의 실시예에 따라, 전달 선호를 서술하는 수신자에 대한 사용자 인터페이스를 나타낸 화면이다.
도9는 본 발명의 실시예에 따라, 병합의 동시발생 및 파이프라이닝(pipelining) 및 전송처리과정을 나타낸 구성도이다.
도10a ~ 도10c는 본 발명의 실시예에 따라, 수신자 목록의 XML 개요표을 나타낸 구성도이다.
도11은 본 발명의 다른 실시예에 따른 메시지 분배 시스템을 나타낸 구성도이다.
도12는 도 11의 시스템 엔진을 나타낸 구성도이다.
도13은 템플릿을 나타낸 구성도이다.
도14는 수신자 기록 내에 포함된 방향변경(redirection)/점증적 증대(escalation) 정보를 나타낸 표이다.
도15는 웹인터페이스의 기능을 포괄하는 규칙을 나타낸 표이다.
도16은 실시된 로그온 화면을 구성도이다.
도17은 주화면의 배열에 대한 일실시예이다.
도18은 사용자를 관찰하는 관리 패널을 나타낸 구성도이다.
도19는 엔터프라이즈 인터페이스 작업 제출 화면을 나타낸 구성도이다.
도20은 상태 보고에 대한 일실시예이다.
도21A ~ 도21A는 작업구성 패널을 나타낸 구성도이다.
도22는 FTP 인터페이스를 통하여 제출된 메시지 작업의 정의를 포함하는 파일을 나타낸 구성도이다.
도23은 메시지 분배 시스템의 아키텍쳐를 나타낸 구성도이다.
도24는 XML 포맷의 수신자 파일을 나타낸 실시예이다.
도25는 데이터베이스 구조의 엔터티 관계를 나타낸 구성도이다.
도26은 서신 작업에 대한 구성 매개변수의 실시예이다.
도27은 Java_Mapping_Class_Resource 레코드에 있는 하나의 자원 형태를 나타낸 구성도이다.
도28은 작업 실행의 흐름을 나타낸 구성도이다.
도29는 벌크 인터페이스, 웹인터페이스, 및 공통 인터페이스를 포함하는 시스템을 나타낸 구성도이다.
도30은 수신자 목록 XML의 개요표이다.
본 발명의 제1태양에 따라, 팩시밀리, 전자우편, 일반우편 및 SMS 메시지 전송을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하는 벌크 통신하는 방법이 실시된다. 바람직하게 이 방법은 미래에 있을 다른 새로운 형태의 매체로 확장될 가능성을 포함한다. 수신자에 대한 정보를 포함하는 분배를 위한 정보는 단일 인터페이스를 통하여 수신된다. 수신된 정보는 하나 또는 그 이상의 템플릿 자료 및 각 수신자를 지정하는 데이터 (임베드할 수 있는 이미지 데이터(embeddable image data)를 포함)를 포함할 수 있다. 수신된 정보를 바탕으로 형성된 최소한 하나의 자료는, 수신자의 전달 선호를 바탕으로, 수신자의 각각에 대하여 전달 매체 중에 지정된 전달 매체를 이용하여 전송된다.
바람직하게는, 벌크통신 방법은 구체화된 전달 매체에 의한 전송이 실패한 수신자들 중에 하나 또는 그 이상의 각각에 대하여, 전달 매체 중에서 다른 전달 매체를 이용하여, 최소한 하나의 자료를 점증적으로 전송하는 단계를 포함한다. 상기 최소한 하나의 자료는 하나의 포맷으로 변환되고, 그 포맷은 각 수신자에 대한 전달 매체 중에서 지정된 전달매체 또는 다른 전달매체에 적합하다. 그 포맷된 자료는 그 전달 매체 중에서 지정된 전달매체 또는 다른 전달 매체를 이용하여 전송용 캐리어로 전송될 수 있다. 전송에 대한 캐리어의 보고는 각 수신자에 대한 자료의 전달에 대한 상태 정보를 제공하도록 처리된다. 차례대로, 점증적 증대 단계(escalating step)는 상태 정보에 종속된다.
또한 벌크 통신 방법은 각각의 수신자에 대하여 최소한 하나의 자료를 제공하기 위하여 하나 또는 이 이상의 템플릿 자료와 각 수신자에 대하여 언급하는 데이터를 병합하는 단계를 포함한다. 또한 각 전달 매체에 대하여 자료 템플릿 형태를 결정하는 단계 및 그 자료 템플릿 형태에 대한 병합과정을 선택하는 단계를 포함한다. 각 수신자에 대하여 지정된 데이터는 각 병합과정으로 제공된다. 전달매체는 미래의 어느 시점에 소정의 병합된 템플릿 자료들의 추가 사본들에 대하여 수신자 요구를 쉽게 충족시키도록 저장소(archiving)을 포함한다.
본 발명의 다른 태양에 따라, 본 발명의 벌크통신 방법을 바탕으로 하여, 팩시밀리, 전자우편, 일반우편 및 SMS 메시지 ( 및 앞으로 확장될 수 있는 새로운 형태의 매체)을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하는 벌크통신을 위한 시스템 및 그를 위한 컴퓨터 프로그램 제품이 실시된다. 본 발명에 따른 이들 태양은 발명의 상세한 설명부분에서 더 상세하게 다루어진다.
수신자의 전달 선호와 병합 점증적 증대를 바탕으로 다중 전달 매체를 통하여 수신자의 단일 셋(a single set of recipients)에 정보를 전달하는 벌크 통신 방법, 벌크 통신 시스템 및 벌크 통신을 위한 컴퓨터 프로그램 제품이 개시된다. 바람직하게는 그 벌크 통신 방법, 벌크 통신 시스템 및 벌크 통신을 위한 컴퓨터 프로그램은 웹서비스로서 전달 서비스를 수행한다. 또한, 전달매체는 일반우편, 전자우편, 암호화 전자우편, 팩시밀리, SMS 및 저장소 ( 및 미래에 있을 다른 매체 형태를 포함)를 포함한다. 본 발명의 실시예를 통하여, 통신망, 통신 프로토콜, MHTML, 포스트크립트와 같은 데이터 포맷을 포함하여 여러 기술적인 사항들이 상세하게 설명된다. 한편 본 발명에서 설명되는 상세한 사항들로부터 변경 및/또는 대체가 본 발명의 범위와 사상에 벗어남이 없이 이루어질 수 있으리라고 당업자라면 쉽게 알 수 있을 것이다. 다른 한편으로는, 본 발명의 기술과 관련된 당업자에게 잘 알려진 사항은 본 발명을 불명료하게 하지 않게 하기 위하여 본 발명의 상세한 설명에서 생략될 것이다.
"점증적 증대(escalation)," "점증적 증대하다 (escalate)," "점증적 증대하기 (escalating),"와 같은 용어와 "점증적 증대(escalate)"의 다른 다른 형태의 용어 는 본 명세서에서 방향변경되기(re-directing)을 의미한다. 따라서 "여러 전달매체들 중에서 하나의 전달매체를 이용하여 최소한 하나의 자료의 점증적 증대 전송(escalating transmission)"라는 어구는 그 전송이 다른 매체를 이용하여 방향변경되는(re-directed) 것을 의미한다.
수신자는 다른 전송 매체들 중에서 하나를 지정하고, 그 지정된 매체를 통하여 정보의 전달이 이루어진다. 또한, 그 정보가 선호된 매체를 사용하여 달성될 수 없다면, 수신자는 매체를 지정할 수 있고, 그 지정된 매체를 통하여 정보가 전달된다. 따라서 정보 전달에 대한 실패가 있는 경우에, 다른 매체에 대하여 점증적인 증대는 수신자의 설정에 따라 발생된다. 바람직하게는 상기 과정은, 객체-지향 방법으로 개발되고, 다중 서브 성분들로 이루어진 컴퓨터 소프트웨어를 이용하여 구현된다. 바람직하게는 소프트웨어에 대한 사용자 인터페이스는 웹서비스로서 구현된다. 더 구체적으로, 소프트웨어 애플리케이션은 자바 및 XML(eXtensible Markup Language)로 제작된다. 이 다음에서는 도면을 참조하여 본 발명의 실시예에 따른 상세한 설명이 이루어짐으로써 일반적인 개념들을 즉시 알 수 있을 것이다.
다음의 일부 설명에서는 컴퓨터 메모리 내에서 데이터를 연산하는 알고리즘과 심볼 표시에 관하여 외연적으로 또는 암묵적으로 설명된다. 이들 알고리즘의 설명과 심볼 표시는, 당업자들이 그들의 작업양을 가장 효과적으로 전달하기 위하여, 데이터를 처리하는 기술을 사용하는 당업자가 사용하는 일종의 수단이다. 하나의 알고리즘이 원하는 결과에 도달하기 위한 단계들의 하나의 자체-일치 시퀀스(a self-consistent sequence)가 된다고 가정하자. 상기 단계들은 물리적인 양을 물리적으로 조작하는 것을 필요로 한다. 통상적으로, 필요하지 않다고 해도, 이들 양은 저장되고, 전송되고, 조합되고, 비교되며 조작될 수 있는 전기신호 또는 자기신호의 형태를 갖는다. 주로 공통적인 용도로 이용되는 때에, 이들 신호들은 편리하게 비트, 값, 요소, 심볼, 문자, 용어, 숫자 등을 나타낸다.
그러나 이와 같은 용어들은 적당한 물리량과 연관되고 이들의 물리량에 적용된 단지 편리하게 표시하는 라벨에 불과하다. 구체적으로 다르게 언급하지 않으면, 다음 용어들로부터 명확해지는 것과 같이, "컴퓨팅," "병합," "계산," "변환," "결정," "비교," "생성," "선택," "출력"등과 같은 용어가 사용되는 문맥은 컴퓨터 시스템 또는 그와 같은 전자기기의 동작 및 처리 과정을 가리키는 것을 알 수 있고, 컴퓨터 시스템이 레지스터 및 메모리 내에서 물리적인 양(전자적인 양)으로 표현되는 데이터를 컴퓨터 시스템 메모리 또는 레지스터 또는 다른 정보 저장소 (storage), 전송기 또는 표시기 내에서 물리량으로서 비슷하게 표현되는 다른 데이터로 조작하고 변환된다는 것을 당업자라면 알 수 있을 것이다.
본 명세서는 방법에 포함된 동작들을 수행하는 장치에 대해서도 개시하고 있다. 상기와 같은 장치는 필요한 목적을 위하여 구체적으로 구성될 수 있거나 컴퓨터에 저장된 컴퓨터 프로그램에 의하여 선택적으로 활성되거나 재구성되는, 범용 컴퓨터 또는 다른 기기를 포함할 수 있다. 여기에서 개시한 알고리즘 및 표시기는 특정한 컴퓨터 또는 다른 장치와 고유하게 관련되지 않는다. 다양한 범용 기계는 본 명세서에서 개시한 내용에 따른 프로그램으로 이용될 수 있다. 또는, 그 방법에 포함된 필요한 단계들을 수행하는 더 특화된 장치는 적절하게 구성될 수 있다. 예를 들어, 다음에 설명할, 계산, 비교 및 선택 단계를 수행할 수 있는 컴퓨터 프로그램이 설치됨으로써, 인터넷 디렉토리 서버 컴퓨터는 그 컴퓨터에 저장된 디렉토리를 모으도록 구성된다.
또한 본 발명의 명세서는 컴퓨터 프로그램 제품이 개시된다. 그 제품은 컴퓨터 프로그램이 저장된, 컴퓨터가 기록 가능한 매체에 저장되고, 그 컴퓨터 프로그램은 저장된 상태에서 그 방법에 포함된 동작들을 수행한다. 컴퓨터가 기록할 수 있는 매체는 소스와 목적지 사이에서 그 컴퓨터 프로그램을 교환할 수 있게 하는 전송매체도 포함한다. 전송매체는, 자기 디스크 또는 광디스크, 메모리 칩과 같은 저장기기 또는 범용 컴퓨터와 인터페이스하기에 적절한 다른 저장 기기를 포함한다. 전송매체는 인터넷 시스템에서 실시되는 유선매체(hard-wired medium)를 포함하거나 GSM 이동 전화기 시스템에서 실시되는 무선매체(wireless medium)를 포함한다. 컴퓨터 프로그램은 어느 특정한 프로그램밍 언어 및 그 프로그래밍 언어의 구현에 제한되지 않는다. 다양한 프로그래밍 언어 및 그 언어의 코딩은 본 명세서에 개시된 내용을 구현하도록 이용될 수 있으리라고 당업자는 쉽게 이해할 수 있을 것이다.
같은 참조번호를 갖는, 단계 및/또는 특징에 대하여 첨부된 도면 중에서 어느 하나를 참조하여 설명될 것이고, 다른 의도가 있지 않는 한, 본 명세서에서 같은 목적을 위하여, 이들 단계 및/또는 특징은 같은 기능 또는 동작을 갖는 것을 전제한다.
본 발명의 상세한 설명을 쉽게 참조할 수 있도록 하기 위하여 본 발명의 상세한 설명은 다음과 같은 표제로 이루어진다.
A. 제1 실시예
I. 개요
II. 메시지 처리
III. 서비스 인터페이스
IV. 꽂을 수 있는 데이터 파일 변환기
V. 자료 병합기
VI. 참조 규칙 처리
VII. 전송기
VIII. 캐리어 인터페이스
IX. 점증적 증대 처리기
X. 보고
XI. 동시발생/병합 파이프라이닝/전송
B. 제2 실시예
I. 개관
II. 개념
III. 웹인터페이스
IV. FTP 인터페이스
V. 시스템 아키텍쳐
VI. 데이터 파일 구조
VII. 데이터베이스 구조
VIII. 자바 매핑 클래스 및 XSL 템플릿
A. 제1 실시예
I. 개요
본 발명의 실시예에 따라 벌크 통신의 방법 및 벌크 통신 시스템의 중요한 태양은 다음을 포함한다.
* 발신자는, 단일 인터페이스를 통하여 하나의 서비스를 이용하고 단일 수신자 목록을 이용하여 수신자들과 벌크통신을 수행할 수 있지만, 호스팅하는 자료 저장 및 검색 시스템( 및 미래에 있을 다른 매체 기술로 확장될 수 있는 가능성 포함)에 대한 전달자료뿐만 아니라 종래우편(일반우편), 전자우편 (암호화 전자우편 및 비-암호화전자우편), 팩스 및 SMS를 포함하는, 다른 모든 현재 이용할 수 있는 매체를 통하여 정보를 전달할 수 있다.
* 전달 선호는 점증적 증대 규칙뿐만 아니라 개인적 수신자를 위하여 지정될 수 있다. 예를 들어, 수신자는 팩스를 통하여 통신문을 수신하기를 선호한다고 지정할 수 있으나, 그 팩스 전송이 실패할 경우에, 바람직하게는, 그 정보는 일반우편으로 수신된다. 이와 같은 상황은 개별적인 수신자에게서 일어나기도 하지만 전반적으로 일어난다.
* 상기 시스템에 관련된 애플리케이션 프로그래밍 인터페이스 (Application Programming Interface (API))가 있다. API를 통하여, 팩스, 전자우편, 암화화 전자우편, SMS, 일반우편 및 저장소(archiving) ( 및 앞으로 이용할 수 있는 형태의 매체)을 이용함으로써 전달이 실행될 수 있다.
* 미래의 전달 매체(예를 들어, WAP, 다른 무선매체, 등)를 쉽게 통합할 수 있도록, 상기 처리 방법은 성분화 방식(componentized manner)으로 설계된다.
* 단일 수신자 목록(single recipient list)은 모든 다른 대상 매체로 전달과정이 이루어질 수 있도록 이용된다. 수신자 목록은 임의의 포맷으로 이루어질 수 있고 그 처리과정에 의하여 그 목록은 XML로 변환된다. 다양한, 입력 수신자 파일 포맷들이 지원되고, 데이터 변환은 XML 포맷으로 실행된다.
* 병합( 개인화)은 모든 다른 전달 매체에 대하여 수신자 목록 내에 있는 필드를 이용하여 실행될 수 있다. 이는 XMS 텍스트 메시지의 개인화, 전자우편 본문 및 제목 텍스트(subject text)뿐만 아니라 워드(Word), 포터블 다큐멘트 포맷(Portable Document Format(PDF)), 하이퍼 텍스트 마크업 언어 (Hyper-Text Markup Language (HTML)), 및 MIME-HTML (MHTML)을 위한 병합자료를 포함한다. MIME 는 다목적 인터넷 우편 확장(Multipurpose Internet Mail Extensions)를 나타낸다. 자료병합은 종래의 XML 자료 포맷 XSL 및 데이터 포맷팅 및 발표용 XSL-FO 스티일시트를 이용하여 지원된다. 상기 서비스는, 일반우편의 우편 집결지(house)를 포함하는 캐리어에 대하여 및 호스팅을 이루는 서비스에 대하여 모든 인터페이스를 관리한다. 발신자 쪽에서 소프트웨어는 설치되거나 관리될 필요가 없다. 다른 캐리어들은 같은 매체 형태를 위하여 지원될 수 있다. 발신자는 선호 캐리어를 지정할 수 있다.
* 발생한 점증적 증대에 대한 보고를 포함하는, 전달 결과의 통합된 보고 및 다른 매체 형태와 교차하는 모든 수신자들에 대하여 성공/실패가 제공된다. 통합된 보고 인터페이스가 제공되어 사용자가 개인적인 수신자의 메시지 전송 및 점증적 증가 상태를 뷰 (view)하게 한다.
* 처리방법은, 복수의 수신자가 종래의 일반우편의 우편 집결지에 의하여 대상이 되는 비슷한 방식으로, 복수의 수신자가 표적이 되는 '벌크우편발송' 시나리오를 위하여 설계된다.
본 발명에 따른 처리 방법 및 시스템은 다른 메시징 서비스에는 없는 특징을 제공하며, 다음에 나열되는 기술 중에서 하나 또는 그 이상을 이용한다.
* 처리는 수신자와 통신할 필요가 있는 공통 요소들을 인식하고 XML 자료에 있는 이들 요소들을 보호한다. 이들 요소들은 수신자의 전달 선호와 점증적 증대 판단 기준 셋을 포함한다. 전달 선호 및 점증적 증대 판단기준은 간단한 기호를 이용하여 서술된다. 독점적인 XML 개요표는 XML 자료 포맷을 설명하도록 정의된다.
* 처리는 원격적으로 접근할 수 있고 안전한 전자 인터페이스 또는 공통 인터페이스를 제공한다. 단일 API는 일치하는 방식으로 모든 폼의 메시지 처리과정을 지원한다. 공통 인터페이스는 FTP (File Transfer Protocol) 또는 SOAP(Simple Object Access Protocol)에 의하여 접근될 수 있다. 상기 인터페이스도 웹 사용자 인터페이스를 통하여 접근될 수 있다.
* 상기 서비스는, 그 서비스가 수신자 데이터를 다양한 자료 포맷으로 병합되게 할 수 있는 데이터 병합 (개인화) 수용성을 제공할 수 있다. 여기서, 다양한 자료 포맷은 PDF, HTML, MHTML, MS 워드 및 텍스트를 포함한다. 바람직하게는 상기 서비스는 데이터 병합을 수행하는 XSL-FO (eXtensible Stylesheet Language Formatting Objects) 포맷팅 엔진을 이용한다. 개인화 수용 능력은 SMS를 통하여 전송되는 메시지뿐만 아니라 전자우편 메시지의 제목 라인 및 본문 텍스트를 개인화하는 능력을 포함한다.
* API는 데이터 변환기를 구체화하는 메카니즘을 지원한다. 상기 서비스는 내장형 특별한 코드를 갖고, 그 특별한 코드는 맞춤형 데이터 변환기들이 동적으로 작성되게(written) 하고 꽂혀질(plugged) 수 있게 한다. 상기 데이터 변환기들은 소정의 포맷(즉, 소정의 기관의 계정 또는 ERP 시스템으로부터 추출되는 것과 같은 방식)으로 수신자 데이터를 구하여, 그 수신자 데이터를 메시징 엔진으로 넣어주기 에 적당한, 공통 XML 포맷으로 변환한다.
* 서비스는 다음의 모든 캐리어 인터페이스를 관리한다: SMS, 전자우편, 암호화 전자우편, 팩스, 종래 우편(일반우편), 및 저장소(archiving). 이는 시스템에 분리된 코드층(code layer)을 구비함으로써 구현되고, 그 시스템은 나머지 메시징 엔진에 공통 캐리어 인터페이스를 제출한다. 또한 이는 미래의 매체 형태가 서비스 (예를 들어, WAP)로 쉽게 병합될 수 있게 한다. 또한 이 서비스는 발신자가 캐리어 선택에 대하여 갖는 선호를 저장할 수 있다.
* 상기 서비스는 모든 다른 자료 템플릿 및 전달매체 형태에 대한 입력 데이터의 단일 셋을 재사용한다. 상기 서비스는 하나의 모듈 또는 성분에 자료 병합을 실행함으로써 그리고 분리된 모듈에서 캐리어 인터페이스로 발표를 위한 포맷을 실행함으로써 상기 재사용 과정을 수행한다.
* 상기 서비스는 단일의 통합된 보고 인터페이스를 사용자에게 제공하고, 그 제공하는 방식은 캐리어로부터 되돌려 받는 다른 형태의 보고를 가져오고 그 보고를 관련 데이터베이스에 저장을 위한 공통 포맷으로 변환함으로써 이루어진다. 그 다음에 상기 서비스는, 전달을 추적하고 점증적 증대 절차를 드라이브하기 위하여 개별적인 메시징 수신자에 대항하여 이들 전달 보고를 중재한다 (reconcile). 이들은 서비스가 개별적인 메시지의 성공과 실패에 대하여 사용자에게 보고를 제공하게 하고 또한 그 서비스가 개별 수신자에게 취해지는 점증적 증대 경로를 나타나게 한다.
* 상기 서비스는 큰 크기의 메시징 처리량을 가능하게 하는 방식으로 구현된다. 상기 서비스는 다른 성분으로 메시징 프로세스의 단계를 갑자기 시작함으로써 이루어진다. 그 다음에 이들 성분은 동시에 수행되고, 그래서 많은 다른 단계들이 동시에 수행된다.
II. 메시지 처리
도 1은 소프트웨어로 구현될 수 있는 메시지 처리절차 (100)를 나타낸 구성도이다. 처리절차는 단계(102)로부터 시작된다. 수신자 데이터 파일 (106), jobDescriptor.XML (108), 및 템플릿 자료 (110)는 API를 통하여 수신된다 (단계 104). jobDescriptor.XML(1808)의 상세한 사항은 이후에 상세하게 설명한다. 단계(112)에서, 작업 매개변수들은 처리되고 데이터 파일은 입력된다. 단계(114)에서, 데이터 변환기가 지정되는지를 결정하기 위한 점검이 이루어진다. 단계(114)가 참(예)으로 회귀하면, 그 처리절차는 단계(116)에서 계속되고 지정된 고객 변환기가 로딩된다. 단계 (118)에서, 데이터는 그 고객 변환기를 이용함으로서 XML로 변환된다. 그 다음에 처리절차는 단계 (120)에서 계속된다. 단계(114)가 거짓(아니오)로 회귀되면, 그 처리절차는 단계 (120)로 계속된다.
단계 (120)에서, XML 수신자 목록이 유효하게 되어 분석되고, 그 다음에 데이터베이스로 저장된다. 이는 저장된 수신자 데이터와 전달 선호(122)를 생성한다. 단계(124)에서, 수신자 전달 선호는 처리되어 다른 매체 형태를 위한 번들로 나뉘어 진다(break up). 단계(126)에서, 각 매체형태에 대한 자료 템플릿 형태를 결정하기 위한 점검이 이루어지고 해당하는 자료 병합기가 선택된다. 자료 템플릿은 특정 매체 형태를 위한 모든 수신자들에 대하여 동일하다. 자료 병합기는 각 개별 수신자의 데이터를 취해서 그 데이터와 자료 템플릿을 병합하여 그 수신자를 위한 개인화된 자료를 생성한다. 자료 템플릿은 XSL 템플릿이 될 수 있다. 또한 MS워드 템플릿 및 HTML 템플릿이 지원된다. 이들은 "템플릿 형태(template Type)"가 된다. 템플릿 형태에 따라, 다른 자료 병합기 (XSL-FO 병합기, MS 워드 병합기, HTML 병합기 등)가 로딩된다. 단계 (126)로부터, 하나 또는 그 이상의 여러 병합 단계들 또는 동작들이 수행된다. 이 병합 단계들은 텍스트병합 (128), PDF 병합(130), 포스트크립트 병합 (132), HTML 병합 (134) 및 MS워드 병합 (136)을 포함한다. 본 발명의 개시와 관련하여 본 발명의 범위와 사상에 벗어남이 없이 다른 여러 병합기 형태가 실시될 수 있음을 당업자라면 쉽게 알 수 있을 것이다. 수신자 데이터 (138)는 병합 단계 (128~136)에 제공된다.
단계(128~136)의 각각으로부터, 그 처리절차는 단계(140)에서 계속된다. 단계 (140)에서, 수신자를 위한 전달 캐리어의 선택에 대한 점검이 이루어진다. 상기 작업의 발신자를 위하여 구성된 각 매체에 대한 선호된 캐리어와 조합하여, 상기 점검은 이전 처리 수신자 전달 선호 단계 (124)의 출력을 재검토함으로써 이루어진다. 이들 두 개의 정보의 조합은 사용된 캐리어 모듈을 결정하기 위하여 사용된다. 팩스가 전송된다면, 그 처리절차는 단계(14~144)를 포함하는 경로를 통하여 계속 진행된다. 전자우편이 전송되면, 그 처리절차는 단계 (148~152)를 포함하는 경로를 통하여 계속 진행된다. 일반 우편이 전송되면, 그 처리절차는 단계 (154~158)를 포함하는 경로를 통하여 계속 진행된다. SMS 메시지가 전송되면, 그 처리절차는 단계(160~164)를 포함하는 경로를 통하여 계속 진행된다. 자료가 저장되면, 그 처리절차는 단계(166~170)를 포함하는 경로를 통하여 계속 진행된다.
팩스 경로에 대하여, 병합된 자료는 비트맵 포맷으로 변환된다. 바람직하게는 그 병합된 자료는 단계 (142)에서 TIFF로 변환된다. 단계(144)에서, TIFF 포맷 자료는 전송을 위하여 팩스 캐리어로 전송된다. 단계 (146)에서, 생성된 팩스 캐리어 보고는 처리되고 분석된다. 전송 상태는 수신자 목록에 설정된다. 그 다음에 처리절차는 단계(172)로 계속된다.
전자우편 경로에 대하여, 병합된 자료는 단계 (148)에서, 필요하다면, MHTML 포맷으로 변환된다. 자료가 PDF, HTML 또는 MS 워드 어태치먼트(attachment)로서 남아 있기 때문에, MHTML로 변환하는 과정은 수행할 필요가 없다. 단계(150)에서, 어태치먼트로서 또는 임베디드 MHTML로서 자료를 포함하는 전자우편 메시지는 전송을 위하여 전자우편 캐리어로 전송된다. 단계 (152)에서, 생성되는 전자우편 캐리어 보고는 처리되고 분석된다. 전송상태는 수신자 목록에서 설정된다. 처리절차는 단계 (172)에서 계속된다.
일반우편 경로에 대하여, 병합된 자료는 단계 (154)에서, 필요하다면, 포스트크립트 포맷으로 변환된다. 단계(156)에서, 포스트크립트 포맷 자료는 전송을 위한 종래의 일반 우편 캐리어로 전송된다. 단계 (158)에서, 생성되는 일반우편 캐리어 보고는 처리되고 분석된다. 전송 상태는 수신자 목록에서 설정된다. 그 다음에 처리 절차는 단계(172)에서 계속된다.
SMS 메시지 경로에 대해서, 병합된 자료는 단계(160)에서, 필요하다면, SMS를 위하여 포맷된다. 단계(162)에서, SMS 포맷 자료는 전송을 위한 SMS 캐리어로 전송된다. 단계(164)에서, 생성되는 SMS 캐리어 보고는 처리되고 분석된다. 그 다음에 전송된 상태는 수신자 목록에서 설정된다. 그 다음에 처리 절차는 단계(172)에서 계속된다.
저장소(archiving) 경로에 대해서, 병합된 자료는, 필요하다면, 저장소(archiving)를 위한 단계 (166)에서 포맷된다. 일반적으로, 상기 포맷은 PDF 또는 포스트크립트이지만, 저장 시스템(archiving system)에 의하여 그 어떠한 특정한 포맷도 지시되지 않았다면 그 포맷은 발신자의 선호에 종속적으로 된다. 단계(168)에서, 포맷된 자료는 저장 시스템(archiving system)으로 전송된다. 단계(170)에서, 저장 시스템(archiving system)에 의하여 생성된 보고가 처리되고 분석된다. 전송 상태는 수신자 목록에서 설정된다. 그 처리절차는 단계(172)에서 계속된다.
단계(172)에서, 점증적 증대는 처리되고, 필요하다면, 수신자 목록상태와 전달 선호 (176)에 종속적으로 된다. 단계(178)에서, 점증적 증대가 필요한지 결정하기 위한 점검이 이루어진다. 단계(178)가 참(예)으로 회귀되는 경우, 그 처리절차는 점증적 증대가 일어나는 수신자에 대하여 단계(124)에서 계속된다. 그렇지 않고, 단계(178)가 거짓(아니오)으로 회귀되는 경우에, 그 처리는 단계(180)에서 종료된다.
도1의 처리절차(100)를 제공하는 소프트웨어 아키텍쳐는, 본 발명에서 인용되는, 호주 가출원 제2002950435의 도11 및 도 11MA~11M의 구성도에 나타나 있다. 호주 가출원 제2002950435에서, 도 11에는 도 11A~도 11M에 있는 구성도의 일부분을 나타내고 있다. 클래스 구성도는 애플리케이션 아키텍쳐의 상세한 설명과 그 애플리케이션을 이루는 성분을 제공한다. 상기 성분은 점증적 증가 처리, 상태 처리, 작업 제출 및 작업 처리, 병합, 포맷팅 및 캐리어 전송을 포함한다. 그 개요표는 여러 태양의 아키텍쳐를 생성한다.
그 처리절차의 추가적인 태양은 아래에서 상세하게 설명한다.
III. 서비스 인터페이스
본 발명의 실시예는 바람직하게는 호스팅 서비스로서 제공되고, 통상적으로 ASP 모델로 알려져 있다. 바람직하게는, 세 개의 다른 접근 방법은 호스팅 서비스를 접근하기 위하여 사용되고, 그 각각은 세 개의 다른 인터페이스 성분에 의하여 지원된다. 상기 서비스 인터페이스 (200)는 도 2에 개시되어 있다. 즉, 도 2는 웹서비스 인터페이스 (SOAP) (210), FTP 인터페이스 (212) 및 웹 그래픽 유저 인터페이스 (브라우저/HTML 기반) (214)를 포함한다. 상기 세 개의 외부 인터페이스 성분 (210, 212, 214)은 같은 근거가 되는 공통의 인터페이스 성분(216)을 이용한다. 바람직하게는 그 같은 근거가 되는 공통의 인터페이스 성분은 XML이 된다.
웹서비스는 UDDI (Universal Description, Discovery and Integration) 및 WSDL (Web Services Definition Language) 표준으로 서술되는 정식 인터페이스가 된다. 호스팅 서비스는 상기 표준을 확인하는 인터페이스 (210)를 제공한다. FTP는 인터넷을 통하여 전송하기 위한 공통 프로토콜이 된다. 호스팅 서비스는 FTP 인터페이스 (212)를 제공한다. 왜냐하면, 이 인터페이스(212)는 발신자가 접근하기에 편리한, 공통적으로 이해되는 인터페이스가 되기 때문이다. 웹 그래픽 유저 인터페이스 (214)는 발신자가 그래픽 사용자 인터페이스를 통하여 수동적으로 작업을 제출할 수 있게 한다.
여러 인터페이스들 (210, 212, 214)은, 도 2에 나타낸 것과 같이, 공통 포맷으로 경량 데이터 (lightweight data)와 마샬 데이터 (marshal data)를 근거 공통 인터페이스 (216)로 전송한다. 인터페이스 매개변수들은 XML 로서 전송된다. XML 개요표는 작업을 설명하기 위하여 정의되어 있다. 상기 개요표는 다른 매체를 위하여 다른 자료 템플릿을 제공하기 위한 메카니즘을 제공하고, 또한 특정한 작업을 위한 다른 선호를 설명한기 위한 메카니즘을 제공한다. 상기 XML 개요표 내에 있는 중요한 태그들을 포함하는, 도 1의 공통 작업 XML 작업 설명 파일 ('JobDescriptor' XML) (108)의 포맷은 표 1에 설명되어 있다.
[표 1]
태그 설명
<job_type> job_type 태그는 전체 작업 형태가 설정되게 허용되고, 이는 매체를 정의하며, 그 매체를 통하여 모든 수신자가 메시지를 전송한다. 상기 태그는 transmission_rules 태그에 대하여 우선이 되고, 이는 금방 발생하려는 점증적 증대 기능성과 함께 이용될 의도가 있으며, 전송 규칙의 셋이 수신자 레벨에서보다 작업 레벨에서 점증적 증대 규칙으로서 제공되는 것을 허용한다.제공된 작업 형태는 다음을 포함한다:<job_type> 팩스로만</작업_형태><job_type> 전자우편으로만</job_type><job_type> 팩스와 전자우편</job_type><job_type> 팩스와 전자우편과 SMS</job_type>(... 등 - 매체의 모든 조합이 허용됨)<job_type> 목록 선호</job_type>LIST PREFERENCE 작업 형태는 수신자 레벨에서 전송 규칙 셋을 이용한다. 더 많은 정보를 위하여 RecipientData.xml에 대한 설명부분 참조
<transmission _rules> transmission _rules 태그는 전송규칙의 셋이 작업 레벨에서 정의되게 한다. 이들 규칙은 특정 작업에 대하여 모든 수신자에게 적용된다. 예를 들어,<transmission_rules>f:e</transmission _rules>
<fax_template> 팩스 템플릿 태그는 템플릿이 팩스 전송 목적을 위하여 생성된 자료가 정의되게 허용된다. 예를 들어,<fax_template>AcmeRelativeImage.xsl</fax_template>
<email_template> 전자우편 템플릿 태그는 템플릿이 전자우편 전송 목적을 위하여 생성된 자료가 정의되게 허용된다. 예를 들어,<email_template>AcmeRelativeImage.xsl</email_template>
<paper_template> 일반우편 템플릿 태그는 템플릿이 일반우편(snail mail)을 통하여 전송된 목적으로 생성된 자료가 정의되게 허용된다. 예를 들어,<paper_template>AcmeRelativeImage.xsl</paper_template>
<email_body_template> 전자우편 본문 템플릿은 텍스트 전자우편 본문이 포함되게 허용하고, 이는 전자우편 매체를 통하여 메시지를 수신하는 모든 수신자에게 전송하게 한다. 이 태그는 전자우편 본문으로서 포함되는 텍스트 데이터를 포함한다. 이 태그는 <<ff_(merge_field_name)>>로 정의된 병합 필드를 포함한다. 상기 병합필드 태그는 alt 키를 누름과 동시에 0171을 타이핑함으로써 <<를 생성하고 alt 키를 누름과 동시에 0817을 타이핑함으로써 >>을 생성된다. 예를 들어,<email_body_template>Dear <<ff_firstname>>,<<ff_month>>월의 첨부된 귀하의 계산서를 확인하십시오.Regards<<ff_creditmanager>></email_body_template>
<email_subject_template> 전자우편 제목 템플릿은 텍스트 전자우편 제목이 포함되게 허용되고, 이는 전자우편 매체를 통하여 메시지를 수신하는 모든 수신자들에게 전송되게 한다. 이 태그는 전자우편 제목으로서 포함되는 텍스트 데이터를 포함한다. 이 태그는 <<ff_(merge_field_namg)>>로 정의되는 병합필드를 포함할 수 있다. 병합필드 태그는 alt 키를 누름과 동시에 << 및 생성될 0817>>를 생성하기 위하여 0171을 타이핑함으로써 생성된다. 예를 들어,<email_subject_template><<ff_month>>월의 첨부된 귀하의 계산서를 확인하십시오.</email_subject_template>
<sms_template> 전자우편 제목 템플릿은 SMS 메시지 본문이 수신자에게 전송되도록 포함되게 허용한다. 이 태그는 SMS 본문으로서 전송되는 텍스트 데이터를 포함하고 <<ff_(merge_field_name)>>으로 정의된 병합 필드를 포함할 수 있다. 상기 병합필드 태그는 alt 키를 누름과 동시에 0171을 타이핑함으로써 <<를 생성하고 alt 키를 누름과 동시에 0817을 타이핑함으로써 >>을 생성된다. 예를 들어,<sms_template>귀하의 <<ff_month>>월의 계산서는 <<ff_emailaddress>> 주소로 발송하였습니다.</sms_template>
<associated_image> 첨부 이미지 태그는 서류 병합의 일부로서 필요한 0~n개의 이미지를 포함하는 것을 허용한다. 예를 들어,<associated_image>Acme.gif</associated_image>
<recipient_list> 수신자 목록 태그는 모든 수신자의 상세한 정보 및 병합 데이터를 제공하도록 이용된 수신자 데이터를 정의한다. 더 많은 정보를 위하여 RecipientData.xml을 설명을 참조. 예를 들어,<recipient_list>AcmeSmall.xml</recipient_list>
IV. 꽂을 수 있는 데이터 파일 변환기
호스팅 서비스를 이용하는 발신자는 특정한 벌크 통신의 일부분으로서 표적이 되는 수신자에 대한 정보를 포함하는 파일을 전송한다. 상기 파일은 기업, 기관 등의 내부 데이터베이스 또는 회계 시스템으로부터 추출될 수 있다. 본 발명의 실시예는 XML 입력 파일에 대하여 표준이 정해져 있고 그에 따라 데이터 변환(300)은, 도 3에 나타낸 것과 같이, 수신자 목록 파일 (310)을 XML (314)로 변환한다. 예를 들어, 수신자 목록 파일 (310)은 텍스트 또는 단층 파일(flat file)이 된다. 이는 데이터 파일 변화기 (312)를 이용함으로써 달성된다. 여기서 데이터 파일 변환기 (312)는 바람직하게는 맞춤형 변환기가 기반 (underlying) 플랫폼으로 플러그(plugged) 되게 하는 성분이다. 입력 파일의 변환은 서비스의 사용자에 대하여 투명하다(transparent). 본 발명의 실시예에서, 데이터 변환은 다음과 같이 구현된다.
* 자바 인터페이스는 CustomMapperInterface로 정의된다.
* 자바 인터페이스는 다음과 정의된 방법을 갖는다:
ConvertFile (Hashmap hm, Dstination d)
* JobDescriptor.xml 입력 파일은, 고객 맵퍼(mapper)가 이용될 수 있는지를 나타내는 'CustomJavaMapping" 태그, 변환 클래스가 지정될 수 있는지를 나타내는 'CustomJavaClassName' 태그 및 파일이름에 대한 고정된 셋(keyed set of file names)이 지정될 수 있는 지를 나타내는 'JabaMappingFile'태그들을 갖는다.
* 작업 처리 엔진은, 커스텀 자바 변환기 클래스 (Custom Java Converter Class)를 기동시키기 위하여 자바의 리플렉션(reflection) 능력을 이용하고, 해쉬맵(Hashmap) 형식으로 JavaMappingFile 매개변수를 커스텀 자바 변환기 클래스(Custom Java Converter Class)에게 건네준다.
* 그 다음에 커스텀 자바 클래스(Custom Java Class) 는 파일 매개변수를 처리하여 변환된 파일을 생성한다.
V. 자료 병합기
본 발명의 실시예는 전달용 데이터를 다른 형태의 매체로 포맷을 수행한다. 도 4는 자료 병합(400)이 다루어지는 방법을 설명한다. XML 수신자 목록 (410) (도 3의 목록 (314)에 대응함)과 XSL 또는 XSL-FO 템플릿 (412)은, 원하는 포맷, 바람직하게는 PDF 또는 HTML로 자료 (416)를 생성하기 위하여 자료 병합기 모듈 또는 성분(414)을 제공한다. 상기 발표 포맷을 수행하기 위하여, XSL 및 XSL-FO 표준은 XML로 포맷팅하고 발표하기 위한 규칙을 정의하기 위하여 사용된다. 자료 병합기 모듈 또는 성분 (414)은 클라이언트에게 전송될 PDF 또는 HTML 자료 (416)를 생성하기 위하여 기반 XML 수신자 목록 (410)으로 선택된 XSL 또는 XSL-FO 템플릿(412)을 적용한다.
수신자의 전달 선호를 바탕으로, 단일 수신자 목록이, 다양한 다른 매체에 대한 데이터를 병합(개인화)하고 전달되게 하기 위하여, 특별한 XML 수신자 목록 개요표 (1000)는 정의되어 있고, 도 10a, 도 10b, 및 도 10c에 나타나 있다. 본 발명에 따른 바람직한 개요표가 도 10에 나타나 있다고 해도, 본 발명의 개시를 바탕으로, 본 발명의 범위와 사상을 벗어나지 않고 그 개요표로부터 많은 변경과 교체할 수 있는 개요표가 있을 수 있으리라고 당업자는 쉽게 알 수 있을 것이다. 상기 개요표(1000)는 다음과 같이 두 부분으로 나뉠 수 있다.
1. 다른 매체에 대한 수신자를 위한 주소 및 선호 판단 기준을 서술하는 전송-규칙-셋.
2. 전송될 자료로 병합될 데이터를 포함하는 수신자-데이터 부분. 수신자 데이터 부분은 본 발명의 XML 개요표에 따라 구성될 수 있다. 또한, 발신자가 XML 개요표에 따라 수신자-데이터의 일부를 구성하도록 허용하는 XML-데이터 서브 요소 형태를 위한 프로비젼(provision)이 있다.
VI. 첨부 규칙 처리
본 발명의 실시예에서 복잡한 규칙을 포함하는, 선호 규칙을 정의하기 위하여 지정된 기호를 사용하여 각각 수신자들에 대하여 지정되게 그 선호규칙이 지정되는 것을 허용한다. 예를 들어, 본 발명의 실시예는 팩스 및 SMS의 전송을 의미하기 위하여 기호 (F:S-P)를 이용하고, 이들 둘의 전송이 실패할 경우에, 일반우편 (서신우편)으로 전송된다. 바람직하게는, 사용자 인터페이스는 전달 선호를 선택하기 위하여 이용되고, 단축 기호는 전달 선호를 서술하기 위하여 이용된다. 전달 매체 형태를 위한 규칙 기호는 표 2에 상세하게 설명되어 있다.
[표 2]
매체 기호
팩스전자우편SMS서신음성저장소암호화 전자우편(암호문)결정될 새로운 매체 형태 E 또는 fE 또는 eS 또는 sP 또는 pV 또는 vA 또는 aC 또는 c
우선 규칙들 및 하나 이상의 매체 형태를 하나의 규칙으로 조합하는 능력을 제공하기 위하여, 여러 연산자들이 사용된다. 목록 선호는, 대쉬(-)로 분리되는, 일련의 규칙으로서 서술된다. 상기 대쉬(-)는, 이전 규칙이 실패하는 경우에 텍스트를 사용하라는 것을 지시한다. 하나의 규칙이 단일 매체 형태 (예를 들어, 팩스를 위한 F) 또는 더하기 기호(+) 또는 콜론(:) 연산자에 의하여 분리된 매체 형태를 서술함으로써 더 단순해질 수 있고, 이 다음부터는 상기 기호를 인용한다. 괄호('('')')는 하나 이상의 매체 형태를 관련시키는 규칙을 포장하기 위하여 사용된다.
대쉬(-) 연산자의 용도를 데모하는 간단한 절차 규칙의 예는 다음과 같다:
E-F-P. (1)
이러한 규칙은 전자우편 전송(규칙 1)을 나타낸다. 규칙1이 실패하는 경우에(예를 들어, 전자우편 주소가 지정되어 있지 않은 경우에), 팩스(규칙2)를 전송한다. 규칙2가 실패하는 경우에, 서신-기반 매체(규칙3)를 통하여 해당 자료(item)를 전송한다.
이들 두 매체가 더하기 기호(+)에 의하여 분리되어 있다면, 이는 그 정보를 그 두개의 특정한 매체 형태(우선순위는 없음)로 전송하라는 것을 나타낸다. 상기 두 매체에 의하여 전송이 이루어질 수 없다면 그 규칙은 실패한다. 예를 들어, 그 규칙 (F+E)은 전자우편과 팩스를 통하여 전송하려는 시도를 나타낸다. 상기 규칙은 팩스 번호와 전자우편 주소가 지정되어 있지 않으면 실패한다.
더하기 기호(+)와 선행 연산자(-)의 조합의 예는 다음과 같다:
(E+F)-P. (2)
상기 규칙은 팩스와 전자우편을 전송하라는 것을 나타낸다. 이들 두 매체가 성공하지 못하는 경우에(예를 들어, 팩스 번호와 전자우편 주소가 주어지지 않았기 때문), 대쉬 연산자(-)는 실행되고 그 처리는 다음 규칙으로 이동한다. 즉, 다음 규칙은 서신에 의한 서류를 전송하라는 것을 의미한다.
두 매체의 형태가 콜론(:)연산자로 분리되어 있는 경우에, 이는 두 특정한 매체 형태(우선순위가 없음, 즉 더하기 연산자(+)와 같음)가 전송되는 것을 의미한다. 그러나 두 매체 중 어느 하나가 전송할 수 없는 경우에 그 규칙은 실패한다. 예를 들어, (F:E)는 전자우편과 팩스로 전송 시도를 나타낸다. 팩스번호 또는 전자우편 주소가 제공되지 않으면 그 규칙은 실패한다. 콜론 (:)연잔자 와 우선순위 연산자(-)의 조합의 예는 다음과 같다:
(E:F)-P. (3)
상기 규칙은 팩스와 전자우편으로 전송하라는 것을 나타낸다. 어느 하나의 전송 매체가 실패할 경우(예를 들어, 팩스번호도 전자우편 주소도 지정되어 있지 않기 때문에)에, 대쉬 (-) 연산자는 실행되고 처리는 다음 규칙으로 이동한다. 즉, 다음 규칙은 서신 우편으로 자료를 전송함을 나타낸다.
다양한 연산자의 우선순위는 다음과 같다: ( ), +, :, -. 괄호는 가장 먼저 수행되고, 더하기 기호는 콜론(:) 연산 전에 수행되며, 이들 연산자들 보다 가장 늦게 대쉬 (-)연산자가 수행된다. 이들 모든 연산자들을 이용하는 복잡한 규칙의 예를 들어, 이들이 어떠한 우선순위 규칙으로 수행되는 지를 살펴보면 다음과 같다:
(E:F+S)-(F:V). (4)
앞서 설명한 대로, 괄호가 최우선순위를 갖기 때문에, 규칙(E:F+S)가 먼저 수행된다. 더하기 연산자(+)는 괄호 안에서 우선순위를 갖기 때문에, 규칙 F+S가 수행된다. 이는 팩스 및 SMS로 정보를 전송하라는 것을 나타낸다. 다음에 콜론(:) 연산자가 수행되어야 하기 때문에, 규칙 E:"F+S"가 수행된다. 이는 전자우편과 "F+S "(팩스와 SMS를 나타냄)로 정보를 전송하라는 것을 의미한다. 전자우편, 팩스 및 SMS로 정보가 전송되는 것을 의미한다. 규칙(F+S)이 실패할 경우가 있다. 왜냐하면, 팩스와 SMS 전송이 실패하기 때문이다. 규칙 E:"F+S"가 실패는 전자우편 또는 "F+S"를 통하여 전보가 전송되는 것이 실패할 경우에 발생한다. 전체적인 제1규칙 E:"F+S"가 실패할 경우에, 대쉬(-) 연산자는 실행되고 다음 규칙 (P:V)이 실행된다. 상기 규칙(P:V)은 서신과 음성으로 정보를 전송하라는 것을 의미한다. 요약하면, 예(4)의 규칙은 전자우편, 팩스 및 SMS 매체를 통하여 정보를 전송하라는 것을 의미한다. 전자우편이 실패하거나 (예를 들어, 전자우편 주소가 나타나 있지 않기 때문임) SMS 및 팩스가 실패할(예를 들어, SMS와 팩스 번화가 없음) 경우에, 정보는 서신과 음성을 통하여 전송된다.
본 발명의 실시예에서, 사용자 인터페이스 성분 또는 모듈은, 동시에 복잡한 규칙의 입력하는 하는 동안에, 간단한 전달 조합의 빠른 엔트리를 허용한다. 도 8에 나타낸 사용자 인터페이스 성분 (800)은 방송 옵션을 나타낸 구성도로서, 팩스, 전자우편, SMS, 음성 및 서신을 포함하는 각 매체 형태에 대한 틱 상자(tick boxes)(802)를 포함한다. 또한, 라디오 단추(804)는 모두에게 전송하고 목록 선호를 이용하여 전송하도록 한다. 사용자는 박스 텍스트 엔트리(box text entry)(806)(예를 들어, (E+S)-F-P)에 목록 선호를 우선적으로 실행할 수 있는 규칙을 지정할 수 있다.
선호 규칙 처리기는 수신자 선호를 해석하여 각 수신자에 대하여 어떠한 전달 매체로 전송되어야 하는지를 결정한다. 도 5는 선호 규칙을 다루는 방법 (500)이 나타나 있다. XML 포맷의 수신자 데이터(510)는 단계(512)로 제공되고, 그러한 경우에 제1 또는 다음 수신자를 위한 선호 규칙이 로딩된다. 단계(514)에서, 처리는 이전 처리가 종료되는 위치로부터 시작한다. 단계(516)에서, 문자가 처리를 위하여 남아 있는지를 결정하는 점검이 이루어진다. 단계(516)가 거짓(아니오)으로 회귀하는 경우에, 규칙의 현재 라운드의 처리는 단계(548)에서 종료된다. 그렇지 않으면, 단계(516)가 참(예)으로 회귀한다면 처리절차는 단계(518)로 계속한다.
단계(518)에서, 실행 분기점은 우선순위 연산자 또는 매체 기호를 나타내는 문자에 따라 수행된다. 단계 (518)이 "(" 또는 ")"를 결정하는 경우에, 처리는 단계(520)에서 계속된다. 단계(520)에서, 어떤 괄호형태가 관련되는 지를 결정하는 점검이 이루어진다. "("가 단계 (520)에서 결정되는 경우에, 처리는 단계 (522)에서 계속되고 열린 괄호가 기록된다. 그렇지 않으면, ")"가 단계 (520)에서 결정되는 경우에, 처리는 단계(524)에서 계속된다. 단계 (524)에서, 닫힌 괄호가 기록되고, 이전 규칙 셋을 위한 그룹이 생성된다. 단계(522 및 524)의 각각으로부터, 처리는 단계 (516)에서 계속된다.
단계(518)가 현재 문자가 철자(F, E , S, P, A, C)인 지를 결정하는 경우에, 처리는 단계(526)에서 계속된다. 단계(526)에서, 그 철자(F, E, S, P, A 또는 C인지를 결정하는 점검이 이루어진다. 단계(526)로 F로 회귀하는 경우에, 처리는 단계(528)로 계속되고 수신자는 팩스목록에 추가된다. 단계 (526)로 E로 회귀하는 경우에, 처리는 단계 (530)에서 계속되고 수신자는 전자우편 목록에 추가된다. 단계(526)로 C로 회귀하는 경우에, 처리는 단계(532)에서 계속되고, 수신자는 암호 전자우편 목록으로 추가된다. 단계 (526)로 P로 회귀하는 경우에, 처리는 단계(534)에서 계속되고 수신자는 일반 우편(서신)목록에 추가된다. 단계(526)가 S로 회귀하는 경우에, 처리는 단계(536)에서 계속되고, 수신자는 SMS 목록에 추가된다. 단계(526)가 A로 회귀하는 경우에, 처리는 단계(538)에서 계속되고 수신자는 저장 목록에 추가된다. 각 단계(528, 530, 532, 534 및 538)로부터, 처리는 단계(516)에서 계속된다.
단계(518)가 현재 문자가 연산자(":," "+," 또는 "-")라고 결정하는 경우, 처리는 단계(540)에서 계속된다. 단계(540)에서, 어는 연산자가 현재 문자인지 결정하는 점검이 이루어진다. 단계 (540)가 "-"로 회귀하는 경우에, 처리는 단계(542)에서 계속되고 "-"심볼 다음에 있는 위치가 기록된다. 그 다음에 처리는 단계(548)로 진행한다. 단계(540)가 "-"로 회귀하는 경우에, 처리는 단P(544)에서 계속되고 "-"(OR)연산자가 기록된다. 처리는 단계(516)에서 계속된다. 단계(540)가 "+"로 회구하는 경우에, 처리는 단계(546)에서 계속되고 "+"(AND)연산자는 기록된다. 처리는 단계(516)에서 계속된다.
VII. 전송기
전송기는 캐리어 인터페이스로 발표를 위한 데이터의 최종 변환을 실행한다. 예를 들어, 팩스전송에 대하여, 자료 병합기 처리로부터 출력되는 PDF 자료는 팩스 캐리어로 발표하기 위한 TIFF 파일로 변환된다. 상기 시스템은 다른 변환기들이 다른 캐리어를 위하여 적절하게 플러그 되는 것을 허용한다.
VIII. 캐리어 인터페이스
캐리어 인터페이스는 최종 데이터 변환을 실행하고 특정 매체 형태를 위하여 그 선택된 캐리어에 대한 전송을 위한 캐리어 특정 파일 포맷으로 배치과정(batching)을 실행한다. 대안 캐리어는 다른 캐리어 인터페이스를 위하여 플러그 될 수 있고, 캐리어 선택은 발신자의 사용자 프로파일의 일부로서 동적으로 구성될 수 있다.
IX. 점증적 증대 처리기
점증적 처리는 캐리어 인터페이스로부터 응답을 점검하고 각 수신자를 위한 전송 결과를 분석한다. 전송이 실패할 경우, 점증적 증대 처리는, 다른 매체를 통하여 통신이 다시 시도되는 지를 결정하기 위하여 수신자 선호 규칙 (선호 규칙 처리기를 통하여)을 이용하고 다른 매체를 통하여 데이터 전송의 재-스케쥴링의 활동을 관리한다. 도 6의 순서도는 점증적 증대 처리절차 (600)를 나타내고 특히 점증적 증대가 전자우편 작업(가장 복잡하게 될 수 있는 전자우편)을 통제하는 지를 나타내고 있다. 다른 매체형태에 대하여, 점증적 증대는 캐리어로부터 되돌려 받은 성공/실패 보고를 바탕으로 간단하게 이루어진다.
도6에서, 처리절차는 전자우편을 캐리어로 전송하려고 시도하는, 단계(610)에서 시작한다. 단계 (612)에서, 미확인 SMTP 서버로 인하여 오류가 발생하는 지를 결정하려는 점검이 결정된다. 단계(612)가 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(624)에서 계속된다. 단계(612)가 거짓(아니오)으로 회귀하면, 그 처리절차는 단계(614)에서 계속된다. 단계(614)에서, 되돌아온 전자우편이 호스팅 서비스(Emdirect)에 있는 발신자(고객)의 우편함에 도착하는 지에 대한 점검이 이루어진다. 단계(614)가 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(622)에서 계속된다. 단계(622)에서, 발신자는, 전자우편 전달이 수신자에 대하여 실패하는 지를 수동적으로 지시한다. 바람직하게, 상기 상황은 웹 인터페이스를 통하여 이루어진다. 그 다음에 그 처리절차는 단계(624)에서 계속된다. 단계(614)가 거짓(아니오)으로 회귀한다면, 그 처리절차는 단계 (616)에서 계속된다.
단계(616)에서, 전자우편을 개봉할 경과시간(timeout)이 만기했는지를 결정하는 점검이 이루어진다. 단계(616)가 거짓(아니오)으로 회귀하는 경우에, 그 처리절차는 단계(618)로 계속된다. 단계(618)에서 그 처리절차는 경과시간이 만기할 때까지 대기하고 그 다음에 그 처리절차는 단계(616)로 진행한다. 단계(616)가 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(620)에서 계속된다. 단계 (620)에서, 전자우편 추적은 전자우편이이 개봉되었는지를 결정하는 점검이 이루어진다. 단계(620)가 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(632)에서 종료하고 점증적 증대는 수행되지 않는다. 단계(620)가 거짓(아니오)으로 회귀하는 경우에, 그 처리절차는 단계(630)에서 계속된다.
단계(624)에서, 발신자의 승인이 점증적 증대를 필요로 하는지를 결정하는 점검이 이루어진다. 단계(624)가 거짓(아니오)으로 회귀하는 경우에, 그 처리절차는 단계(630)에서 계속되고, 다음 매체 형태로 점증적 증대가 발생한다. 그렇지 않으면, 단계(624)는 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(626)에서 계속된다. 단계(626)가 거짓(아니오)으로 회귀하는 경우에, 그 처리절차는 단계(628)로 계속된다. 단계(628)에서, 수동 발신자의 승인 이벤트가 웹 인터페이스를 통하여 대기된다. 그 다음에 처리절차는 단계 (626)에서 계속된다. 단계(626)가 참(예)으로 회귀하는 경우에, 그 처리절차는 단계(630)에서 계속된다. 상기 절차에 대한 더 상세한 사항은 아래에서 설명한다.
점증적 처리절차는 다음 기능성을 제공한다:
* 선택적 여분 (사용자 레벨에서 구성됨)으로서 점증적 증대 기능성을 제공하고 그에 따라 요금을 부과하는 능력.
* 점증적 증대가 특정한 작업에 필요한지를 서술하기 위한 작업 레벨에 있는 능력.
* "목록 선호"가 작업 제출에 대하여 선택되는 경우에, 수신자 전달 선호에 따른 작업을 수행하기 위한 점증적 증대의 능력.
* "목록 선호" 이외의 방송선택이 사용되는 경우, 서술된 선택을 따르는 점증적 증대를 위한 능력 (예를 들어, 전자우편+팩스+서신에 대하여, 먼저 전자우편이 수신자에게 전송되는 시도를 하고, 그 전자우편 전송 시도가 실패하면, 그 다음에 팩스 전송을 시도하고, 팩스 전송이 실패하면 서신 전달이 시도된다).
* 발신자가 점증적 증대 처리에서 수동적으로 방해하고 어느 점증적 증대가 진행되어야 하고 진행되지 말아야 하는 지를 지시하는 능력.
* 점증적 증대를 필요로 함으로써 사용자가 전자우편을 수동적으로 플래그 하는 능력 (그래서 발신자는 그 회신이 도착하고 그 웹사이트로 가서 점증적 증대가 필요함에 따라 마크 표시하는 것을 알 수 있다).
다른 매체 형태에 대하여, 점증적 증대 기준은 다음과 같다. 일부 매체 형태에 대해서, 대안적인 메카니즘이 설명되었다. 대안들이 이용될 수 있는 경우에, 발신자에게는 선택권이 있고 그 선택권의 점증적 증대의 판단기준은 발신자가 적용하려고 하는 것이다. 이는 발신자의 사용자 선호의 일부로서 구성된다.
팩스가 지정된 번호로 재시도를 수행한 후에도 전송될 수 없다면, 점증적 증대가 발생한다. 이는 유효하지 않은 팩스 번호로부터 지정된 팩스 기계에 연결되는 네트워크의 장애(NCN)에 이르기 까지 다양한 원인으로 인하여 발생한다.
전자우편이 지정된 요일의 번호 내에 수신자가 개봉함으로써 추적되지 않으면, 점증적 증대는 발생한다. 전자우편 회신의 그 어떠한 자동적 처리가 실행될 수 없지만, 그 작업의 제출자가 특정 전자우편이 (웹 인터페이스를 통하여) 성공적으로 전송되지 않았음을 수동적으로 지시함으로써 편리하게 작업이 이루어진다. SMS 번호가 연락될 수 없으면 (즉 무효함), 점증적 증대는 발생한다. 이는 보고 수준이 모바일 서비스 제공자가 제공될 수 있는 지에 종속적으로 된다.
일반우편 주소가 성공적으로 바코드로 될 수 없다면, 점증적 증대는 발생한다. 우편 주소를 바코드로 할 수 없는 능력은 여러 원인이 있을 수 있다. 예를 들어, 우편번호가 없는 경우, 무효한 우편번호인 경우, 특정한 거리에 대하여 무효한 거리 번호인 경우.
점증적 증대와 관련하여 다음 사용자 선호를 저장하기 위한, 사용자 구성 화면에 대하여, 다음 필드가 이용될 수 있다.
* 개봉에 대한 어떠한 기록도 없는 경우에 전자우편을 점증적으로 증가할 수 있는가?
* 상기 질문에 긍정적이면, 점증적 증가가 발생되기 전에 전자우편이 개봉될 필요가 없는 날들의 수는?
* 웹 인터페이스를 통하여 점증적 증대가 필요한 것과 같이 전자우편을 수동적으로 표시할 능력을 원하는가?
* 점증적 증대가 실질적으로 발생하기 전에 수동적으로 방해하기를 원하는가?
구성된 '점증적 증대'를 갖는 발신자에 대하여, 웹 인터페이스를 통하여 제출된 모든 작업은, 활성으로 스위칭된 점증적 증대를 자동적으로 갖는다. 점증적 증대는, 선택된 방송 선호에 따라 처리한다. 즉 목록 선호가 그 방송 선호로 선택되는 경우에, 점증적 증대는 개인적인 수신자의 목록 선호에 따라 처리한다.
구성된 점증적 증대를 갖는 발신자에 대하여, 추가적인 선택권은 JobDescriptor.XML 파일에 있는 FTP 인터페이스를 통하여 이용될 수 있다. 이는 '점증적 증대' 플래그가 된다. '점증적 증대'플래그가 '예'로 설정되면, 그 점증적 증대는 상기 작업을 신청(지원)한다. 점증적 증대는 선택된 방송 선호에 따라 처리한다. 즉 목록 선호가 방송 선호로서 선택되는 경우에, 점증적 증대는 개별적인 수신자의 목록 선호에 따라 처리한다.
점증적 증대 이벤트가 수신자에 대하여 발생하는 경우에, 작업처리 엔진은 각 수신자의 전달 상태를 추적하여 점증적 증대 경로를 따라 수신자를 이동시킨다 (예를 들어, 불량 팩스 보고의 접수, 또는 X 일 내에 전자우편의 미개봉, 또는 특정 작업이 점증적 증대를 필요로 한다는 것에 대하여 사용자에 의한 수동적 플래깅).
전자우편에 대한 점증적 증대의 수동적 플래깅은 웹 인터페이스를 통하여 설정된다. 작업을 제출한 후에, 발신자는 그 작업을 검색할 수 있고 그 다음에 '추가 전자우편 점증적 증대' 단추를 선택한다. 이는 발신자에게 모든 전자우편 수신자의 목록을 제공하고, 발신자가 점증적 증대를 수행하기를 원하는 수신자들의 옆에 있는 '점증적 증가하는'상자를 발신자는 점검할 수 있다. 상기 화면의 목적은 발신자가 전자우편 바운스(email bounce)를 받는 상황을 마련하고 그럼으로써 점증적 증대가 필요하다는 것을 수동적으로 나타낸다. 이와 같은 편리성은 발신자/전송자가 다른 이전 지식을 갖는 다른 상황을 제공하고, 그 다른 이전 지식은 수신자는 그 전자우편을 수신하지 않을 것이라는 것이다 (예를 들어, 회계부로 전자우편을 전송하는 경우, 일반 전자우편 연락은 공휴일에 가능하다는 것을 알고, 팩스/서신이 전송되기를 원하고 그들 대신에(stand-in) 팩스/서신을 접수한다.)
점증적 증대 상태: 작업을 제출한 후, 사용자는 임의의 시간에 작업을 검색할 수 있고 그 다음에 모든 수신자의 현재 상태를 관찰하며 수신자가 점증적 증대를 했는지 또는 점증적 증대를 처리하기 위하여 발신자의 승인을 기다리고 있는지를 결정한다. 점증적 증대를 위한 원인도 보여준다 (예를 들어, "세 번의 재시도 후에 팩스 전송 실패," "5일 안에 미개봉된 전자우편," "주소에 대하여 무효한 거리번호," "점증적 증대에 대한 수동적인 플래그" 등).
점증적 증대 처리: 점증적 증대 상태 화면으로부터, 발신자는 그 프로파일에 구성된 '수동적 간섭'을 갖는다면, 발신자는 '처리 점증적 증대' 기능을 선택할 수 있다. 이는 점증적 증대를 대기하는 수신자 목록을 표시한다. 점증적 증대 이벤트를 갖는 수신자에 대하여, 그 수신자의 상태를 위한 라인 옆에 '처리' 점검 상자가 마련된다. 발신자가 점증적 증대를 처리하기를 희망하여 "선택된 점증적 증대 처리" 단추를 누름으로써, 발신자는 일부 수신자 또는 모든 수신자에 대하여 체크 표시를 할 수 있다.
메시지 재시도: 점증적 증대 상태 화면으로부터, 발신자도 '메시지 재시도' 기능을 선택할 수 있고, 이는 점증적 증대를 대기하는 수신자 목록을 표시한다. 점증적 증대하는 대신에, 발신자는 특정한 수신자에 대하여 '재시도' 또는 '수정된 주소로 재시도'를 선택할 수 있다. '수정된 주소로 재시도'가 선택되었다면, 사용자는 수정된 팩스 번호, 전자우편 주소 또는 일반 우편주소를 위하여 그들을 유발시키는 화면을 먼저 표시한다. 두 개의 선택사항에 대하여, 애플리케이션은 오래된 상세정보 또는 갱신된 상세정보를 이용하여 그 수신자에게 재-전송 시도 처리를 수행한다. 사용자는 그들이 재전송을 원하는 각 수신자에 대하여 상기 절차(한번에)를 실행한다. 재전송 시도가 성공하면, 더 이상 점증적 증대 상태가 일어나지 않는다. 재전송 시도가 실패하는 경우에, 수신자는 대기하는 점증적 증대 상태로 되돌아간다. '수정된 주소로 재시도'가 선택되기만 하면, 발신자는 그들 자신의 데이터베이스를 갱신하도록 발신자를 상기시키기 위하여 원래의 상세정보 및 수정된 상세정보의 사본을 전자우편으로 전송한다.
점증적 증대 이벤트가 수신자의 셋에 대하여 발생하는 경우(실패를 나타내는 팩스 상태 보고의 접수 또는 대안적으로 전자우편이 점증적 증대를 필요로 하는 것을 표시하기 위하여 이용되는 "기간에 의한 개봉"의 시간경과)에, 전자우편을 그 작업을 제출한 발신자에게 전송된다. 그 다음에 발신자는, 발신자가 구성된 "수동 간접" 옵션을 갖는 경우에 점증적 증대를 수동적으로 처리하기 위하여 웹상에서 점증적 증대 상태 화면으로 갈 수 있다.
X. 보고 성분
보고 성분은 캐리어 인터페이스로부터 전달보고를 수신하고, 관련 데이터베이스로 저장을 위한 하나의 공통 상태 포맷으로 전달보고를 조합한다. 보고 성분은 통합된 전달 보고를 생성하고 보기 위하여 발신자가 사용하는 그래픽 인터페이스와 툴로 이루어진다 (웹 기반 HTML 인터페이스를 통하여 이들을 보거나 전자우편을 통하여 이들을 수신함).
도 7은 웹사이트가 발신자에게 통합된 보고를 전송하기 위하여 다른 캐리어 보고가 분석되고 데이터베이스에 저장되는 방법을 처리하는 절차가 나타나 있다. 단계(710 에서, 처리절차는 메시지 작업을 제출함으로써 시작된다. 단계(712)에서, 수신자 정보는 수신자 데이터(714)의 데이터베이스에 저장된다. 단계(716)에서, 메시지는 FTP를 통하여 캐리어로 전송된다. 단계(718)에서, 보고는 FTP를 통하여 캐리어로부터 수신된다. 단계(720)에서, 캐리어 보고는 분석되고 수신자 전송 결과는 데이터베이스에 저장된다. 전송은 단계(722)에서 종료된다. 단계(720)로부터 상태는 수신자 데이터베이스에서 갱신된다.
분리되었지만 관련된 처리과정에서, 발신자로서 사용자는 단계(726)에서 상태 보고를 요청할 수 있다. 수신자 데이터베이스에 있는 갱신된 상태 정보는 단계(726)의 다음에 있는 단계(728)로 제공된다.
XI. 동시발생/병합 경로/전송
호스팅 서비스는 병합과 전달 처리를 가능하게 하는 하부 태스크가 동시에 일어나게 하는 방식으로 설계된다. 이와 같은 설계는 호스팅 서비스 내에서 높은 수준의 처리율을 가능하게 하고 호스팅 서비스가 지원하는 복잡한 점증적 증대 절차를 제공하게 한다. 도9는 다른 성분(902, 904, 906)의 다중 실시예(900)가 그 데이터의 처리율을 동시에 스프림라인으로 동작하는 방법을 나타내고 있다. 특허, 병합기 모듈(902)의 다중 실시예는 동시에 동작하고 각각의 다중 동시 전송기 모듈 (904)에 그 출력을 제공한다. 전송기 모듈(904)은 차례대로 각각의 다중 캐리어(906)에 연결된다.
B. 제2 실시예
I. 개관
본 발명의 실시예는, 수신자 전달 선호를 바탕으로 다중 전달 매체 (팩스, 전자우편, SMS, 일반 우편 및 저장소)를 통하여 수신자 단일 셋으로 정보를 전송하고, 및 전달 실패의 경우에 수신자의 선호에 따라 다른 매체로 점증적 증대를 병합하는 벌크 통신하는 방법, 벌크 통신하는 시스템 및 벌크 통신하는 컴퓨터 프로그램 제품(웹 서비스)과 관련된다. 컴퓨터 소프트웨어는 다중 서브-성분으로 이루어지는, 객체지향 방식으로 개발되고 있다. 그 소프트웨어에 대한 사용자 인터페이스는 바람직하게는 웹 서비스로서 전달된다.
메시지 브로드 서비스는 다음 기술을 이용한다:
(A) 상기 시스템은 고객과 통신할 필요가 있는 공통 요소들을 인식하여 XML자료로 그 요소들을 포장한다. 이들 요소들은 고객의 전달 선호와 방향변경(redirection) 판단기준 셋을 포함한다. 전달 선호 및 방향변경(redirection) 판단기준은 유일한 단축 기호를 이용하여 설명된다. 독점적인 XML 개요표는 XML 자료 포맷으로 서술되기 위하여 정의된다.
(B)상기 시스템은 원격으로 접근할 수 있고 보안성이 있는 전자 인터페이스를 제공한다. 단일 데이터 스트림은 일관된 방식으로 모든 메시지 형식을 지원한다. 데이터 스트림은 상호작용 웹 사용자 인터페이스를 통하여 제공될 수 있고 또는 인터넷을 통하여 비-상호작용 벌크 제출에 의하여 (FTP 또는 다른 프로토콜 수단에 의하여) 제공될 수 있다.
(C) 상기 시스템은 데이터 변환기를 서술하기 위한 메카니즘을 지원한다. 상기 시스템은 내장된 특정 코드를 갖고, 그 특정 코드는 맞춤형 데이터 변환기가 동적으로 작성되고 꽂혀지게 될 수 있다. 상기 데이터 변환기는 소정의 포맷으로 수신자 데이터를 얻어서 (예를 들어, 발신자의 계정 또는 ERP 시스템으로부터 추출함으로써) 그 데이터를 메시징 엔진에 넣기 위하여 공통의 XML 포맷으로 변환한다.
(D) 상기 시스템은 데이터 병합(개인화) 능력을 제공하고, 그 데이터 병합 능력은 상기 시스템이, PDF, HTML, TIFF, MS 워드 및 텍스트를 포함하는, 다양한 자료 포맷으로 수신자 데이터를 병합하게 한다. 상기 시스템은 XSL-FO 포맷팅 엔진을 사용하여 데이터 병합을 실행한다. 개인화 능력(capability)은 SMS를 통하여 전송된 메시지뿐만 아니라 전자우편 메시지에서 제목 라인과 본문 텍스트를 개인화하는 능력을 포함한다.
(E) 상기 시스템은, SMS, 전자우편, 팩스, 종래 우편(일반우편) 및 저장소와 같은 모든 캐리어 인터페이스를 관리한다. 이는 그 시스템에서 분리된 코드층을 가짐으로써 이루어지고, 그 시스템은 공통 캐리어 인터페이스를 나머지 메시징 엔진으로 전송한다. 또한 이는 미래 매체 형태를 그 시스템 (예를 들어, WAP)으로 쉽게 병합되게 한다.
(F) 상기 시스템은 단일의 통합된 보고 인터페이스를, 캐리어로부터 되돌려 받는 다른 형태의 보고를 얻어서 관련된 데이터베이스에 저장하기 위한 공통적인 포맷으로 그 보고를 변환하는 사용자에게 제공한다. 그러면, 상기 시스템은 전달을 추적하고 점증적 증대 절차를 구동하기 위하여 개별 메시지 수신자에 대한 이들 전달 보고를 일치시킨다. 이는 상기 시스템이 개별적인 메시지의 성공과 실패에 대하여 사용자에게 보고를 제공하고 개별 수신자를 위하여 취해진 방향변경 (redirection) 경로를 표시하게 한다.
(G) 상기 시스템은 큰 크기의 메시지 처리율을 가능하게 하는 방식으로 구현된다. 이는 메시지 처리의 단계들이 다른 성분들로 나뉘어짐으로써 달성된다. 이들 성분들은 동시에 실행되고, 그래서 많은 다른 단계들이 동시에 실행된다.
* (A) 전달 선호는 방향변경(redirection) 규칙뿐만 아니라 개별 수신자에 대하여 서술될 수 있다. 예를 들어, 수신자가 팩스를 통하여 통신문을 수신하기를 선호한다고 서술될 수 있으나 팩스 전송이 실패할 경우 일반우편으로 전송되는 것을 선호한다고 서술될 수도 있다.
* (B) 하나의 데이터스트림이 있고, 그 데이터스트림에 의해서 수신자 정보가 상기 시스템으로 제공된다. 이를 통하여 하나의 스트림 전달은 팩스, 전자우편, SMS, 일반우편 및 저장소를 통하여 실행될 수 있다.
* (C) 수신자 목록은 소정의 포맷이 될 수 있고 그 시스템은 그 목록을 XML로 변환한다.
* (D) 병합 (개인화)은 모든 다른 전달 매체(SMS 텍스트 메시지, 전자우편 본문 및 제목 텍스트뿐만 아니라 워드, PDF, MTML 및 MHTML을 위한 자료 병합을 포함)에 대하여 수신자 목록 내에 있는 필드를 사용하여 실행될 수 있다.
* (E) 상기 시스템은 모든 인터페이스를 캐리어(일반우편의 우편집결소와 호스팅 저장 서비스)로 병합한다. 발신자쪽에서는 어떠한 소프트웨도 설치하거나 관리할 필요가 없다.
* (F) 하나의 단일 수신자 목록은 모든 다른 대상 매체를 통하여 전달을 위하여 사용될 수 있다.
* (G) 발생한 점증적 증대와 다른 매체의 형태를 가로지르는 모든 수신자에 대한 성공/실패에 대한 보고를 포함하는, 전달 결과의 통합 보고.
* (H) 상기 시스템은, 복수의 수신자들이 대상이 되는 벌크 우편전송 시나리오를 위하여 의도적으로 설계된다. 즉, 복수의 수신자들이 종래의 일반 우편 우송집합소에 의하여 목표가 되는 방법과 같은 비슷한 방식으로 설계된다.
* 회사 및 기관은 하나의 인터페이스를 통하여 하나의 시스템을 이용하여 그들의 고객과 벌크통신을 실행할 수 있지만, 호스팅 자료 저장 및 검색 시스템으로 자료를 전달할 수 있을 뿐만 아니라, 종래 (일반) 우편, 전자우편(암호화 및 비-암호화함), 팩스 및 SMS를 포함하는, 현재 이용할 수 있는 모든 매체를 통하여 단일 수신자 목록을 이용하여 고객에게 자료를 전달할 수 있다.
* 개별적인 수신자 레벨에서 뿐만 아니라 전반적인 레벨에서 전달 선호와 방향변경(redirection) 규칙에 대한 명세표를 지원한다.
* 상기 시스템은 팩스, 전자우편 및 SMS 캐리어에 대한 인터페이스를 관리하고 종래 (일반) 우편의 우편집결소를 관리한다.
* 상기 시스템은 다양한 입력 수신자 파일 포맷을 지원하고 XML 포맷으로 데이터 변환을 실행한다.
* 상기 시스템은 종래의 XML 자료 포맷, 데이터 포맷팅과 발표를 위한, XSL 및 XSL_FO 스타일시트를 이용하여 자료 병합을 지원한다.
* 상기 시스템은 높은 메시지 처리율을 가능하게 하는 방식으로 구현된다.
* 상기 시스템은 사용자가 개별적인 수신자의 메시징 및 점증적 증대의 상태를 관찰하게 하는 통합된 보고 인터페이스를 제공한다.
상기 기술은, 통상적으로 알려진 애플리케이션 서비스 제공자(ASP) 모델로 알려진 호스팅 서비스 또는 전적으로 실시된 모델의 폼으로서 제공된다. 상기 시스템에 접근하는 세 개의 다른 방법이 있고 이들 세 개의 접근 방법은 두 개의 다른 인터페이스 성분에 의하여 지지된다. 두 개의 외부 인터페이스 성분 모두는 같은 기본 공통 인터페이스 성분을 이용한다. 도 29는 벌크 인터페이스 (3010), 웹인터페이스 (3012) 및 공통 인터페이스 (3020)를 포함하는 시스템 (3000)을 나타내는 구성도이다.
A. 웹 그래픽 사용자 인터페이스 (브라우저/HTML 기반) (3012)
그래픽 사용자 인터페이스를 통하여 작업을 수동적으로 제출하기를 원하는 엔터티에 대하여, 웹브라우저 기반 MTML 인터페이스 (3012)는 그 시스템에 제공된다.
B. 벌크 인터페이스 (3010)
인터넷을 통하여 작업의 벌크 전송이 지원된다. 이는 고객 ERP 시스템이 직접적으로 그 시스템에 작업을 전송하는 것을 허용한다. FTP는 인터넷을 통하여 파일을 전송하는 일반적인 프로토콜이다. 상기 서비스는 벌크 인터페이스(3010)로서 FTP 인터페이스를 제공한다. 왜냐하면 상기 인터페이스는, 엔터티들(entities)이 접근하기 쉬운, 공통적으로 이해되는 인터페이스가 되기 때문이다. 범용 서술 표준, 발견 통합(Universal Description Discovery and Integration (UDDI))표준 및 웹서비스 정의 언어(Web Services Definition Language(WSDL)) 표준에 의하여 서술되는 정식 인터페이스와 같은 다른 제출 인터페이스들도 이용될 수 있다.
C. 공통 인터페이스 (3020)
모든 다양한 인터페이스들 (3010, 3012)은 경량화(lightweight) 되고, 도 29에 나타낸 것과 같이, 기본 공통 인터페이스 (3020)로 전송하기 위한 공통 포맷의 마샬 데이터(marshal data)가 된다. 인터페이스 매개변수는 XML로서 분석된다.
보고 성분은 캐리어 인터페이스로부터 전달 보고를 수신하고, 관련된 데이터베이스로 저장되기 위한 하나의 공통 상태 포맷으로 보고를 조합한다. 이와 같은 성분은 화면과 툴로 구성되고, 이들은 사용자가 통합된 전달 보고를 생성하고 관찰하게 하는 데에 사용된다 (웹 기반 MTML인터페이스를 통하여 이들을 관찰할 수 있거나 전자우편을 통하여 이들을 수신할 수 있음). 도 7은, 웹사이트가 통합된 보고를 사용자에게 전송하도록, 다른 캐리어 보고가 분석되고 데이터베이스에 저장되는 방법을설명하기 위한 구성도이다.
수신자 전달 선호를 바탕으로, 단일 수신자 목록이, 다양한 다른 매체에 대한 데이터의 통합(개인화)과 전달을 위하여 사용되는 메카니즘을 제공하기 위하여, 특별한 XML 개요표가 정의된다. 수신자 목록 XML 개요표는 도 30에 나타나 있다.
중요한 차이점은 다음과 같다:
* 메시지 분배 시스템은, 수백 또는 수천의 수신자에게 메시지를 방송하기 위한, 범용목적의 제품이다.
* 데이터는 메시지 분배 시스템으로 소정의 전자 포맷으로 전송되고, 그 메시지 분배 시스템은 프린트스트림에 제한되지 않으며 여러 시스템을 포함한다.
* 메시지는 각 수신자에 대하여 확장적으로 개인화될 수 있다.
* XML 기술은 강력한 병합의 편리성을 지원하는 섬세한 메시지 템플릿들을 정의하기 위하여 이용된다.
* 메시지 분배 시스템은 데이터 변환기 또는 자바 매핑 클래스로 알려진 강력한 특징을 포함한다. 이는 메시지 분배 시스템이 소정의 포맷으로 수신자 정보를 수용하게 한다.
* 메시지는 팩스, 전자우편, 서신 또는 SMS로 전송될 수 있다. 새로운 매체 형태 (예를 들어, PDA)가 쉽게 추가될 수 있다. 저장소 (출력 메시지가 저장함에 복사될 수 있게 함)의 출력 매체 형태의 설계는 진행중에 있다.
* 각 수신자는 다른 매체 형태를 서술할 수 있다. 따라서 단일 메시지 분배는 서신, 전자우편, 팩스 등에 의하여 수신자들에게 전송될 수 있다.
* '방향변경(redirection)' 특징이 제공된다. 메시지가 수신자의 제1선택 매체에 전달될 수 없다면, 메시지 분배 시스템은 서술된 제2선택 및 제3선택을 바탕으로 시도를 수행한다. 따라서, 예를 들어, 특정한 수신자에게 팩스 전송이 실패할 경우, 메시지 분배 시스템은 자동적으로 전자우편, 서신 또는 그 밖의 매체 형태로 전송을 시도한다. 전송 규칙은 각 수신자에 대하여 개별적으로 서술되거나 필요에 따라 전체 작업에 대하여 전체적으로 서술된다.
본 발명의 제2실시예에서, 전자 메시지 방송 시스템 (1100)은 도 11에 나타나 있다. 메시지 분배 시스템 (1100)은 일대다 상황을 다루기 위하여 구체적으로 설계되고, 여기서, 단일 메시지 (1110)는 메시지 분배 시스템(1100)에 의하여 수신된다 (그리고 특히 시스템 엔진 (1120)에 의하여 수신됨). 또한 상기 메시지 분배 시스템(1100)은 수십, 수백 또는 수천의 목적지(1130)로 방송하도록 구체적으로 설계된다. 메시지 분배 시스템은 각 수신자에 대하여 개별적으로 '잘라지는(tailored)' 메시지를 위하여 편리성을 제공한다. 메시지는 인터넷을 통하여 수신되고 전송되거나 전용 통신 링크에 의하여 전송된다.
메시지는 텍스트, 그래픽, 임베드 오디오/비디오, 실질적으로는 전자기적으로 표현될 수 있는 가상적인 그 어떤 것을 포함할 수 있다.
메시지 분배 시스템은 메모리로부터, 마케팅 자료, 청구서 및 계산서에 이르는 광범위의 정보를 방송하기 위하여 사용될 수 있다.
도12는 도 11의 시스템 엔진(1120)의 전체적인 아키텍쳐를 상세하게 나타낸 구성도이다. 인터넷 인터페이스 (1210)는 애플리케이션 서버(1220)와 연결되고, 이는 차례대로 데이터베이스 서버(1240)로 연결된다. 애플리케이션 (1220)은 PC 하드웨어 (1232), 예를 들어 MS 윈도 2000 운영체제를 이용하여 구현될 수 있다.
애플리케이션 서버(1220)는 자바 가상 머신 (1228), JDBC (1230), 아파치 톰캣 웹 서버(1224) 및 JBoss 애플리케이션 서버 (1226)를 포함한다. 애플리케이션 서버 (1220)는 자바 프로그램과 유틸리티를 포함하는 애플리케이션 소프트웨어(1222)를 포함한다.
데이터베이스 서버 (1240)는 PC 하드웨어 (1246), JDataConnect (1224) 및 SQL 서버 (1242)위에 운영체제 레벨 (예를 들어, MS 윈도 2000)을 포함한다.
바람직하게 상기 운영체제는 안전한 데이터 센터에 위치한 컴퓨터에서 동작한다. 다른 메시지 분배 시스템은 다른 장소에 위치한 데이터 센터에 설치된다. 시스템 소프트웨어(1220)는 바람직하게는 자바 프로그램밍 언어로 작성되어 다수의 제3의 유틸리티 패키지를 포함할 수 있다 (그 패키지의 대부분은 자바 플랫폼을 위해 설계 된다). 메시지 분배 시스템은 데이터를 표현하기 위하여 XML 표준을 사용한다.
메시지 분배 시스템은 광범위한 플랫폼에서 동작한다. 예를 들어, 그 시스템은 MS 윈도 2000 운영체제를 이용하는, PC '애플리케이션 서버'(1232, 1246)에서 동작할 수 있다. 자바 프로그램 환경은 아파치 톰캣 웹 서버(1224) 및 JBoss 애플리케이션 서버 (1224)에 의하여 제공된다.
모든 지속적인 데이터는 다른 PC '데이터베이스 서버'(1240)에 있는 메시지 분배 시스템 데이터베이스에서 유지되고, 그 PC 데이터베이스 서버(1240)는 자바 JDBC 인터페이스 (1230)를 통하여 접근된다. 데이터페이스 소프트웨어는 MS SQL 서버(1242)가 될 수 있고, 이는 메시지 분배 시스템 서버와 연결된 링크를 다루기 위한 JDataConnect 소프트웨어(1244)를 이용한다.
II. 개념
메시지 분배 시스템은 바람직하게는 대량 메시지 시장을 위하여 구체적으로 개발된 소프트웨어 한 벌로서 구현된다. 그 시스템은 메시지 분배 시스템 엔진으로 알려진 메시징 컴퓨터를 제어한다.
메시지 분배 시스템은 전송자로부터 메시지(즉, 텍스트, 그래픽, 소리/영상 파일, 등의 전자적으로 표현됨)를 수용하여, 그 메시지의 복사본을 복수(수십, 수백 또는 수천을 의미함)의 수신자로 분배한다. 일반적으로 전송자는 소정의 종류의 기관이고 수신자들은 개인 또는 다른 기관이 된다. 전송자는 고객이 될 수 있고 고객 id로 식별될 수 있다. 여기서, 용어 "전송자(sender)"와 "고객(customer)"은 문맥에 따라 본 명세서에서는 상호 맞교환되게 이용된다. 메시지 내용은 각 수신자에 대하여 구체적으로 나뉘어질 수 있으나 메시지의 전체적인 포맷은 통상적으로 모든 수신자에 대하여 비슷하다. 예를 들어, 전송자가 은행이고 메시지가 월별 은행 계산서를 발행한다고 가정하자. 메시지의 전체 포맷(즉, 은행명, 은행 로고, 칼럼 표제(column heading) 등)은 모든 수신자에 대하여 같으나 상세한 사항 (즉, 수신자 성명과 주소, 계좌 잔액(account balance) 및 개인적인 신용/빚 거래)은 각 수신자에 대하여 다르다.
수신자로부터 메시지를 받아들이고 수신자에 대하여 메시지의 다중 복사본을 분배하는 전체적인 처리과정은 작업이라고 불리운다. 하나의 작업이 종결되면, 메시지 분배 시스템은 자동적으로 전송자를 위한 작업 상태 보고를 준비한다. 이러한 보고는 작업의 출력을 요약하고 (즉, 얼마나 많은 수신자 메시지들이 성공적으로 전달되고 어떻게 많은 수신자들이 실패했는 지를 보여 줌) 개별적인 수신자 기반에 대하여 성공/실패의 상세한 사항을 제공한다 (예를 들어, 특정한 수신자에 대하여 전달이 몇 번 시도되었고 그 전달이 실패한 이유를 보여줌).
메시지 분배 시스템은 각 수신 메시지 전송의 결과에 대하여 더 상세한 정보를 포함하는 과금 기록의 셋을 마련한다. 과금 기록은 회계 시스템으로 전송되고, 그 과금 기록은 월말에 고객에게 청구서를 발행하는 데에 이용된다.
각 고객은 하나 또는 그 이상의 메시지 분배 시스템의 계정(각 계좌 ID에 의하여 구분된다)을 갖고 있다. 각 작업은 하나의 계정과 연관되어야 한다. 계정은 작업에 대하여 소정의 동작 특성을 정의(예를 들어, 팩스 페이지의 최대 크기, 필요한 인쇄의 품질, 이용될 수 있는 메시지 분배 시스템의 특징, 등)하고, 과금 과정에서 그 작업에 대하여 고객에게 얼마나 청구해야 할지를 결정하는 데에 이용된다. 고객은 기관 단위(요금 센터, 부서 또는 엔터프라이즈 내의 기타 부서들)로 적당하게 구성된 계정들의 그룹을 할당한다.
전송자는 온라인 웹 인터페이스를 이용하여 메시지 분배 시스템과 일반적으로 상호 연락한다 (즉, 작업 제출, 작업 상태 보고 검색, 등). 고객은 이와 같은 작업을 위하여 그 기관 내에 소정의 개인들을 지명한다; 이들 개인들은 사용자들로서 알려진다 (그리고 고객 내에서 유일하게 정해지는 사용자 ID에 의하여 식별된다). 사용자들은 인터넷 탐색기 또는 네스케이프와 같은 웹브라우저를 이용하여 웹 인터페이스에 접근한다.
경우에 따라서, 웹 인터페이스에 대한 방안으로서, 사용자는 FTP 파일 전송기를 이용하여 인터넷을 통하여 메시지 분배 시스템으로 작업을 제출할 수 있다. 이러한 선택사항은 이후에 설명한다.
수신자는 다양한 캐리어에 의하여 전달되는 여러 다른 매체를 통하여 그 메시지를 수신할 수 있다.
* 전자우편 - 메시지 분배 시스템은 캐리어에게 전자적으로 메시지를 전송한다. 여기서 캐리어는, 전자우편 본문에 이식됨 및/또는 첨부물로서 어느 쪽을 이용해서든지, 전자우편으로서 메시지를 수신자의 전자우편 주소로 전달한다.
* 서신 - 메시지 분배 시스템은 캐리어에게 전자적으로 메시지를 전송한다. 여기서, 캐리어는 메시지를 인쇄하고, 봉투에 인쇄된 메시지를 위치시키고 우편 시시템을 통하여 수신자에게 메시지를 우송한다.
* SMS - 메시지 분배 시스템은 캐리어에게 전자적으로 메시지를 전송한다. 여기서, 캐리어는 수신자의 이동 전화기로 텍스트로서 메시지를 전송한다.
* 팩스 -메시지 분배 시스템은 캐리어에게 전자적으로 메시지를 전송한다 .여기서, 캐리어는 수신자의 팩시밀리 기기로 메시지를 전송한다.
다른 매체는 앞으로 소개될 것으로 예상할 수 있다. 시스템 아키텍쳐는 최소한의 개발 노력으로 새로운 매체가 소개되는 것이 지원될 수 있도록 설계된다. 출력 메시지가 저장 파일로 전송되는 것을 허용하는 '저장소' 매체가 구현될 것이다.
앞서 나열한 모든 매체는 유일하게 어드레스(번지)로서 지시될 수 있다. 그 번지는 지정 ID를 가리킨다.
지정 ID의 포맷은 각 매체형태에 대하여 다르다. 팩스 기계와 이동 전화기에 대하여, 지정 ID는 전호번호가 된다. 서신에 대해서 지정 ID는 우편 주소가 된다. 전자우편에 대해서 지정 ID는 전자우편 주소가 된다. 따라서 특정한 수신자는, 예를 들어, 다음 지정 ID를 갖는다:
* 팩스 지정 ID +61 2 1234 5678
* SMS 지정 ID +61 438 987654
* 서신 지정 ID NSW 레오나르도-가 워라타-주 24번지 (우편번호 2065) P. 존즈 귀하
* 전자우편 지정 ID [email protected]
하나의 지정 ID는 매체 형태마다 할당된다. 지정은 하나의 수신자를 기반으로 한다는 조건이 붙는다; 특정한 작업의 경우 각 수신자는 복수의 다른 매체 및 복수의 다른 지정들을 갖는다는 조건이 붙을 수 있다.
작업을 시작하기 위하여, 사용자는 템플릿 파일 및 수신자 파일을 메시지 분배 시스템으로 제출한다. 하나의 작업은 하나 또는 그 이상의 템플릿을 필요로 한다. 하나의 템플릿 파일은 오직 단일 템플릿을 포함한다. 하나의 작업은 각 전달 매체에 대하여 하나 또는 그 이상의 템플릿을 필요로 한다. 예를 들어, SMS와 전자우편을 다루는 하나의 작업은 SMS 메시지에 대하여 하나의 템플릿을 필요로 하고 전자우편 메시지에 대하여 다섯 개의 템플릿(전자우편 제목에 하나의 템플릿, 전자우편 본문의 텍스트 버전에 대한 템플릿, 전자우편 본문의 HTML 버전에 대한 템플릿, 그 두 개의 전자우편 첨부물에 대한 두 개의 템플릿)을 필요로 할 수도 있다.
템플릿은 복수의 다른 포맷으로 제공되는데, 이들 포맷은 어도브 아크로벳 PDF (PDF) 포맷, TIFF 이미지 (TIF) 포맷, 포스트크립트(PRN) 포맷, SML 스타일시트(XSL) 포맷, MS 워드(DOC) 포맷, 및 단순한 텍스트 (TXT) 포맷을 포함한다.
각 템플릿은 메시지의 불변의 부분을 설명한다(예를 들어, 모든 수신자에게 동일한 부분).
소정의 템플릿 형태(예를 들어, 오직 DOC, XSL 및 TXT)는 '개인화'할 수 있다 (예를 들어, 이들은 선택적으로 하나 또는 그 이상으로 '병합필드'를 포함할 수 있다). 또한 XSL 템플릿은 '템플릿 아티팩트 파일'이 동반할 수 있다.
* 병합필드는 템플릿 내에서'위치 홀더'라고 이름이 붙혀진다. 각 병합필드는 하나의 위치를 가리키고, 그 위치에서 수신자-특정 데이터는 메시지 분배 시스템이 특정한 수신자에 대하여 메시지를 생성하는 시점에 삽입된다. 따라서, 예를 들어, 템플릿은 'cust_name,' 'account_balance,' 및'date'라고 불리는 병합 필드를 포함하고, 이는 도 13에 나타낸 것과 같이 템플릿(1300)내에 나타날 수 있다.
* 도시할 목적으로, 도13의 예는 '샤브론(chevron)' 문자에 의하여 범위가 정해지는 병합 필드를 나타낸다. 이는 그 병합 필드가 DOC 템플릿 및 TXT　템플릿에서 실질적으로 어떻게 나타나는 지를 보여준다 (그러나 XSL 템플릿 내에서는 나타나지 않음)
* 템플릿 아티팩트 파일은 XSL 템플릿 파일을 수반한다. 이는 그래픽 파일, 오디오 파일, 비디오 클립 파일 또는 다른 멀티미디어 파일을 포함한다. 예를 들어, 은행 계산서 메시지가 로고를 포함하는 경우에, 템플릿 파일은 적당한 그래픽을 포함하는 이미지 파일 (예를 들어, BankLog.jpg라고 함)을 수반할 수 있다.
작업은 하나 또는 그 이상의 수신자 파일을 필요로 한다. 수신자 파일이 수신되는 경우, 메시지 분배 시스템은 모든 수신자 파일을 단일 파일로 연결하거나 조합한다. 이 파일의 내용은 수신자 목록으로서 알려진다.
수신자 목록은 많은 수신자 레코드를 포함한다 (예를 들어, 수백 또는 수천의 수신자 레코드). 각 수신자 레코드는 하나의 의도된 수신자 메시지를 설명하는 텍스트를 포함할 수 있다. 수신자 레코드는 다음 정보를 포함한다.
* 수신자 정보- 그 기록은 수신자의 이름 및 참조 코드와 같은 수신자에 대한 기본 정보를 포함한다.
* 지정 ID - 각 매체에 대한 하나의 지정 ID가 있고, 이를 이용하여 메시지는 수신자에게 전달될 수 있다. 따라서, 예를 들어, 하나의 수신자가 전자우편 또는 팩스로만 메시지를 수신할 수 있으면, 수신자 레코드는 전자우편 주소 및 팩스 전화 번호만을 포함한다; 서신 및 SMS에 대한 지정 ID는 정보없음(null)으로 표시된다(이는 수신자가 우편 또는 SMS에 의하여 연락할 수 없음을 나타낸다). 지정 ID가 지정되었다는 사실은 그 지정 ID가 사용되고 있음을 반드시 의미하지는 않는다. 특정한 메시지를 전달하기 위하여 이용된 지정 ID는 '지정 선호 정보'라고 구체화한다.
* 병합 값- 수신자 레코드는 템플릿 필드에 있는 '병합필드'에 대응하는 '병합값'을 포함한다. 메시지 분배 시스템이 수신자에 대하여 메시지를 생성하는 경우에, 병합값은 메시지 분배 시스템에 의하여 병합 필드에 위치된다. 예를 들어, 템플릿이 "<<account_balance>>"라고 불려지는 병합필드를 포함할 수 있고 특정한 수신자 기록은 '451.34달러' 라는 병합 값을 포함할 수도 있다. 그 메시지가 수신자에게 전달되면, '451.34달러' 라는 텍스트는 그 병합 필드 이름 대신에 메시지에 표시된다.
* 지정 선호 정보- 지정 선호 정보는 메시지 분배 시스템에게 어느 지정을 통하여 메시지를 전해야 할지를 표현한다.
* 각 수신자에 대하여, 전달의 구체적인 번호(예를 들어, 3)에 이르러서, 시도는 지정 선호 정보의 일부로서 지정될 수 있다. 각 시도는 전송의 구체적인 번호 (예를 들어, 3)에 이르렀음을 다른 지정 ID에게 알린다; 이들의 첫 번째는 마스터(master) 전송이고 나머지는 복사 전송이 된다.
* 메시지 분배 시스템은 첫 번째 시도를 시작한다. 상기 시스템은 동시에 마스터 전송과 복사 전송을 전송한다. 마스터 전송이 수신자에 도달하는 것이 실패하면, 메시지 분배 시스템은 다음 시도를 수행한다. 그 처리 절차는 마스터 전송이 성공적으로 종료되거나 모든 시도의 수가 소진될 때까지 계속된다.
* 마스터 전송을 전달하기 위한 다중 시도는 방향변경(redirection)이라고 알려진 방식으로 이루어진다. '복사(copy)' 전송의 실패는 메시지 분배 시스템에서 중요하게 간주되지 않고 방향변경(redirection)을 초래하지는 않는다.
* 상기 언급한 내용은 도 14의 실시예를 통하여 나타나 있다. 수신자 레코드 (1400)는, 도 14에 나타낸 것과 같이, 시도 및 전송을 지정하고 있다. 메시지 분배 시스템은 팩스로 초기에 마스터 전송을 전송하고, 동시에 전자우편으로 복사전송을 전송한다. 마스터 전송(예를 들어, 팩스)이 성공하면, 그 수신자의 처리는 종료된다.
마스터 전송이 성공하지 못하면 (예를 들어, 팩스 번호가 혼선이 있거나 입수할 수 없으면), 메시지 분배 시스템은 시도 번호 2를 시작한다 (예를 들어, 그 시스템이 서신으로 마스터 전송을 전송하려고 시도하고 SMS로 그 복사본을 전송하려고 시도한다). 이는 메시지 분배 시스템의 처리의 종료를 표시한다. 왜냐하면 세 번째 시도는 지정되어 있지 않기 때문이다.
III. 웹인터페이스
사용자와 메시지 분배 시스템 사이의 상호작용은 웹브라어저 인터페이스에 의하여 발생한다. 메시지 분배 시스템과 상호작용을 시작하기 위하여, 사용자는 단순하게 웹브라우저를 시작하고 (예를 들어, MS 인터넷 탐색기 또는 넷스케이프사의 네비게이터) 적당한 URL을 입력한다.
URL을 입력하면 사용자와 메시지 분배 시스템 엔진 사이의 논리적인 링크가 이루어지고 이는 도16에 나타낸 '로그온 화면'이 표시된다.
다음에는 메시지 분배 시스템에 의하여 표시되는 화면에 대하여 설명을 하고 이들이 어떻게 사용되는지에 대하여 설명한다.
고객, 사용자 및 계정
웹인터페이스는 '사용자'('고객'을 나타내고 메시지 분배 시스템에서 계정을 동작시킴)가 메시지 분배 시스템에 작업을 제출하는 것을 허용하여 이들 동작을 수행하게 한다.
시스템 운영자의 조직 내에서, 임원 그룹이 있을 수 있고 이 그룹은 메시지 분배 시스템의 연산 제어를 책임지고 메시지 분배 시스템의 고객을 지원한다. 여기에서 그들은 메시지 분배 시스템의 지원팀을 가리킨다. 지원팀은 그 시스템에 대한 전체적인 관리 책임이 있고 특히 그 시스템을 이용하는 새로운 고객을 설정하는 작업을 수행한다.
메시지 분배 시스템의 지원팀의 부원이 그 시스템에 새로운 고객을 소개하는 경우에, 그 팀 부원은 메시지 분배 시스템 데이터베이스에 다음과 같은 항목을 생성한다.
* 고객에 대한 정보를 포함하는 단일 'CUSTOMER' 레코드.
* 여러 'ACCOUNT'레코드, 여기서 각 'ACCOUNT' 레코드는 그 고객이 이용할 수 있는 계정에 대한 정보를 포함.
* 관리자 사용자들(administrator users) (즉, 특권을 갖는 사용자들)을 설명하는 하나 또는 그 이상의 'USER'레코드 .
* 고객의 관리자 사용자들(customer's administrator users)은 표준 사용자들이 그 관리가 고객 지향 제어 하에 있도록 그 고객(즉, 관리자 특권을 갖지 않은 사용자들)을 위한 하나 또는 그 이상의 표준 사용자들을 생성하도록 허용한다. 그러나 관리자 사용자들은 메시지 분배 시스템 지원팀에 의하여 생성될 수만 있다.
메시지 분배 시스템은 특정한 고객과 관련된 정보를 유지한다. 상기 정보는 고객의 계정 정보, 사용자 정보 및 그 고객의 사용자들에 의하여 제출된 여러 작업들에 대한 정보를 포함한다. 상기 정보는 접근 제어 뷰(view)로부터 '폐쇄 그룹(closed group)'를 포함하여 형성한다. 고객 사용자들은 계정, 그 고객과 관련된 사용자들 및 작업들에 대한 정보에만 접근할 수 있다. 사용자들은 다른 고객들에 대한 정보에 접근할 수 없다. 이는 메시지 분배 시스템이 갖추어야할 안정성의 문제이다.
이에 대한 하나의 예외가 있다. 메시지 분배 시스템 지원팀은 '통제'고객 ID을 갖는 '특정한 고객'으로서 메시지 분배 시스템 내에 등록될 수 있다. 상기 특정 고객('통제 사용자들')에 속하는 사용자들은 메시지 분배 시스템 지원팀에 의하여 수행되는 감독관 역할에 맞는 특별한 권한을 갖는다. 특히 통제 사용자들에 대해서만 다음과 같은 권한을 갖는다:
* 관리자 사용자들은 고객, 사용자, 소정의 고객에 대한 계정 정보에 접근하고 변경할 수 있는 권한과 소정의 고객에 대한 작업을 제출할 수 있는 권한을 갖는다
* 표준 사용자들은 고객, 사용자, 소정의 고객에 대한 계정 정보를 볼 수 있는 (변경할 수는 없음) 능력과, 작업을 제출할 수 있고 소정의 고객에 대한 전자우편의 오류를 보고할 수 있는 능력을 갖는다
통제 사용자들은 소정의 임명된 고객의 사용자를 흉내 낼 수가 없고, 그에 따라 통제사용자들이 그 고객을 나타내는 것과 같이 하여 그 시스템을 접근할 수 없다. 하나의 고객이 상기와 같은 방식으로 통제 사용자에 의하여 흉내낼 수 없는 경우에, 그 고객은 프록시 고객(proxy customer)으로 알려진다.
여러 형태의 사용자들이 수행할 수 있게 허용되는 웹 인터페이스 기능을 지배하는 규칙은 도 15에 나타낸 표에 표시하였다. 도15에 나타난 기능들의 설명은 다음과 같다.
도15의 각주"1"로 표시한 기능들은 특정-고객을 나타낸다. 이들은 지명된 프록시 고객들을 위하여 수행된다 (통제 사용자는 먼저 특정 프록시 고객을 지명하고 그 다음에 기능을 수행한다). 다른 통제 고객 기능은 프록시 고객의 지명을 먼저 요구하지 않는다. 도 15의 각주"2"와 관련하여, 사용자들은 그들 자신의 USER 레코드에 대한 소정의 필드들을 변경하는 것을 허용할 수 있지만 다른 사용자의 USER 레코드들은 변경할 수 없다.
로그 온
사용되는 로그온 스크린(1600)은 도 16에 나타나 있다. 사용자는 그 로그온 화면(1600)에 고객 ID, 사용자 ID 및 비밀번호를 입력한다.
화면 배열
일단 사용자가 성공적으로 로그온하면, 도 17에 나타낸 주화면 (1700)이 표시되고, 사용자가 그 화면에 '취소'를 누르기 전까지 계속해서 그 주화면은 남아 있는다. 주화면은 왼쪽에 주메뉴의 폼과, 다른 메뉴들에 대해서는 위쪽을 가로질러 일련의 탭의 형태를 갖는다. 도 17에 이와 같은 내용이 표시되어 있다.
왼쪽에는 주 메뉴가 차지하고 있다 ('주메뉴1,' '주메뉴2,' 등). 현재 선택된 주메뉴의 선택은 검은 테두리로 그 선택을 둘러쌈으로써 나타내고 있다 (도 17의 '메뉴2').
화면의 위는 고객이름 (그 다음에 브라켓으로 고객 ID를 표시함 )과 사용자명(그 다음에 브라켓으로 사용자 ID를 표시함)을 포함한다. 사용자명과 사용자 ID는 현재 로그온한 사용자를 식별하기 위한 것이다. 고객명과 고객 ID는 사용자를 소유하는 고객을 나타내거나, 고객이 '통제'대상이라면, 프록시 고객을 나타낸다. 프록시 고객과 관리자 사용자들은 이탤릭체로 표시된다.
관리
관리 패널 그룹은 고객의 USER 레코드 및 ACCOUNT 레코드가 보여지는 것을 허용하고, 다른 경우에는 변경된다.
사용자를 볼 수 있게 하는 패널의 예는 도 18에 나타낸다. 이 패널에 대한 여러 변형예가 있을 수 있다. 즉, 정상 사용자를 위한 패널, 고객(또는 통제) 관리자 사용자용 패널, USER 레코드에 의하여 표현되는 특정한 사용자용 패널이 있을 수 있다. 도 18은 관리자 사용자에 의하여 보여지는 패널(1800)을 나타내고 있다.
통제 관리자 사용자들 및 고객 관리자 사용자들은 상기 패널의 소정의 필드에 정보를 넣을 수 있다. 대부분의 표준 사용자들에 대하여, 모든 필드는 "읽기만"할 수 있다. 상기 레코드를 적용하는 표준 사용자에 대해서, "비밀번호"필드, "접속"필드 및 "시험 지정"필드를 제외한 모든 필드는 "읽기만"할 수 있다.
대부분이 필드들은 데이터베이스에서 USER 레코드에 있는 필드들에서 '일대일'대응을 갖는다. "사용자가 제출할 수 있는 작업에 대한 계정"의 목록에 있는 체크 표시된 항목들은 'USER_ACCOUNT_XREF'레코드를 반영한다.
메시지 분배 시스템 작업 제출
사용자는 두 개의 인터페이스 중에서 하나의 인터페이스를 이용하여 메시지 분배 시스템으로 작업을 제출할 수 있다.
* 엔터프라이즈 인터페이스
엔터프라이즈 인터페이스는 일반적으로 큰 엔터프라이즈에서 사용되고, 이는 그들의 고객과 제공자들을 추적하고 관리하는 섬세한 컴퓨터 시스템들을 소유한다. 엔터프라이즈 인터페이스는 청구서와 계산서와 같은 '기본적 우편'에 초점이 맞추어져 있다.
* 이와 같은 경우, 메시지 포맷은 복잡 (로그와 다른 그래픽이 병합됨)하지만 자주 바뀌지 않는다. 이는 적당한 템플릿 개발이 시간 소비의 주요인이 되지만 일단 완성만 되면 자주 반복될 필요가 없다.
* 엔터프라이즈 인터페이스 고객을 위한 템플릿은 고객의 상세사항에 대한 메시지 분배 시스템 지원팀에 의하여 개발된다. 완전한 템플릿은 회사의 통제하에서 메시지 분배 시스템의 데이터베이스 내에 저장된다. 고객이 작업을 운영할(run)할 때마다, 시스템은 템플릿을 참조하지만 (적당한 작업 형태를 인용함으로써) 템플릿 자신은 변하지 않고 고객에 의해서 변경될 수도 없다.
* 엔터프라이즈 인터페이스를 이용하는 고객은 연락을 위한 상세정보와 공급자, 고객, 임원, 동업자, 등에 대한 다른 정보들을 포함하는 데이터베이스(고객 소유의 컴퓨터 시스템 내에)를 갖는다. 그래서, 고객들이 메시지 분배 시스템을 통하여 다양한 수신자에게 메시지를 전송하려고 할 경우, 고객들은 그들 소유의 데이터베이스에 대항하는 '데이터베이스 추출'프로그램을 동작시켜 수신자 파일을 생성한다.
* 엔터프라이즈 인터페이스 템플릿은 XMS 시타일시트(XSL) 포맷에 저장된다. 이에 대하여 병합 필드를 포함하지 않는 전자우편 첨부물의 경우는 그 예외 사항이 된다. 그 첨부물은 어도브 아크로벳 PDF 포맷에 지정된다.
* 수신자 파일 포맷은 넓게 변화하지만, 수신하자마자 메시지 분배 시스템은 모든 파일 포맷을 XML 포맷으로 변환한다.
* 엔터프라이즈 인터페이스를 이용하는 애플리케이션의 하나의 예로서 월별 은행 계산서 작업을 고려해 보자. 계산서의 전체적인 포맷(즉, 헤딩, 로그, 반복 사용어구 텍스트, 등)은 은행에 의하여 일정하게 바뀌지 않는다. 상기 포맷은 은행의 상세사항에 대한 메시지 분배 시스템 지원팀에 의해 개발된 XSL 템플릿 파일의 셋에 의하여 서술된다. 그러나, 계산서 상세사항 (고객이름, 주소, 거래 상세사항, 계좌 잔액, 등)은 매달 각 고객에 대하여 달라진다. 일반적으로, 계산서 상세사항은 은행의 메인 프레임의 데이터베이스의 프로그램에 의하여 추출되고 매월 수신자 파일로서 메시지 분배 시스템으로 전송된다.
* 표준 인터페이스
표준 인터페이스는 더 작고 덜 복잡한 작업에 대하여 이용된다.
* 표준 인터페이스의 사용자는 사용자 자신의 템플릿 파일을 마련하는 데에 책임이 있고 사용자가 작업을 시작하기만 하면 그 템플릿 파일을 공급하는 데에 책임이 있다. 이는 템플릿이 상대적으로 간단한 상황에서 유용하다(예를 들어, 메모, 출판 발매 및 간단한 워드 프로세서를 이용하여 마련될 수 있는 마케팅 캠페인). 이와 같은 상황에서, 새로운 템플릿 파일이 각각의 메시지 분배 시스템 작업에 대하여 마련되는 것은 공통적이다.
* 어떤 경우에는 (즉, 간단한 텍스트 정보가 관련되는 경우), 사용자는 표준 인터페이스를 통하여 온라인으로 사용자 템플릿 파일을 입력할 수 있다. 또 다른 경우에는, 사용자는 오프라인으로 템플릿 파일을 마련할 수 있다 (예를 들어, MS 워드 'DOC' 포맷으로).
* 수신자 파일은 '콤마 분리 값'(comma separated values (CSV))이 될 수 있으나, 수신하자마자 메시지 분배 시스템에 의하여 XML 포맷으로 변환될 수 있다.
표준 인터페이스는 고객에게 적합하고, 그 고객은 간단한 메모 또는 마케팅 자료를 빠르게 생성하기를 희망하고 그 메시지를 다른 고객들에게 방송하기를 희망한다. 엔터프라이즈 인터페이스는, 포맷이 일정 기간에 대하여 지속되는 경우, 계산서 및 청구서와 같은, 기존의 애플리케이션에 적합하지만 그 기간동안 반복적으로 이용될 수 있다.
다음 표3과 4는 기술적인 용어를 기준으로 상기 두 인터페이스 사이의 차이점을 정리하였다.
[표 3]
특징
엔터프라이즈 인터페이스 표준 인터페이스
템플릿과 관련된 이미지는 메시지 분배 시스템 데이터베이스에서 미리 결정되어 저장됨 템플릿들은 각 작업에 제출
병합할 수 있는 템플릿은 XML 스타일시트(XSL) 포맷임 병합할 수 있는 템플릿은 MS 워드(DOC) 포맷 또는 단순한 텍스트 (TXT) 포맷임
수신자파일은 소정의 포맷일 수 있다 (그러나 메시지 분배 시스템에 의하여 변환된다) 수신자파일은 CSV 포맷일 수 있다 (그러나 메시지 분배 시스템에 의하여 XML로 변환된다)
전자우편, 팩스, SMS 또는 서신으로 출력될 수 있음 전자우편, 팩스 또는 SMS로 출력될 수 있으나 서신으로는 출력이 안됨
[표 4]
템플릿 포맷
템플릿 형태 엔터프라이즈 인터페이스 표준 인터페이스
중간 용도 병합가능 비-병합가능 병합가능 비-병합가능
서신 하나 또는 여러 쪽 XSL " " "
팩스 제목 쪽 XSL " TXT "
아나 또는 여러 쪽 XSL " DOC PDP, 포스트크립트, TIFF
전자우편 제목 라인 XSL " TXT "
HTML 본문 XSL " " HTML
텍스트 본문 XSL " " TXT
첨부 XSL PDF DOC 임의 포맷
SMS 메시지 텍스트 XSL " TXT "
캐리어에게 전송된 메시지의 대응 포맷은 다음 사항을 변화시킨다:
* 각 서신 메시지는 포스트크립트 파일로서 캐리어에게 전송된다.
* 각 팩스 메시지는 하나 또는 그 이상의 TIFF 파일(플레인 텍스트 포맷(plain text format)으로 특별한 헤더에 포함된 '제목' 정보를 갖음)로서 캐리어에게 전송된다.
* 각 전자우편 메시지는 복합적인 포맷으로 캐리어에게 전송되고, 그 복합적 포맷은 다음과 같다:
- 주제 라인은 특별한 제어파일에 있는 평이한 텍스트 폼으로 코딩된다.
- HTML 및 텍스트 본문은 HTML 파일 및 평이한 텍스트 파일로 각각 코딩된다.
- 엔터프라이즈 인터페이스 첨부물은 PDF 파일로서 전송된다.
- 표준 인터페이스 첨부물은 최초 수신된 것과 같은 포맷으로 전송된다.
* 상기 규칙에 대하여 예외 사항은 DOC 포맷의 표준 인터페이스 첨부물은 PDF 포맷으로 캐리어에게 전송된다.
* 바람직하게는, 표준 인터페이스에 의하여 다루어지는 HTML 파일은 완전하게 자급자족한다 (그 파일들은 이미지 파일과 같은 외부의 아티팩트(artifacts)에 대한 참조(references)를 포함하지 않는다).
* 각 SMS 메시지는 다음 폼으로 이동전화기로 전송된다.
사용자는 먼저 계정을 선택하고 그 계정에서 작업이 운영된다. '드롭다운(drop-down)' 목록은 사용자가 사용할 것을 위임한, 모든 고객의(또는 프록시 고객의) 계정의 이름을 나열한다. 사용자가 '제출' 단추를 클릭하면, 엔터프라이즈 또는 표준 인터페이스를 반영하는 새로운 패널이 표시된다(선택된 계정에서 설명되는 것과 같이).
메시지 분배 시스템 작업 제출
도19는 엔터프라이즈 인터페이스 작업 제출 화면 (1900)의 배열을 나타낸다.
* 작업 참조
- 작업 참조 필드는 선택적이다. 사용자는 그에게 의미가 있는 작업의 이름을 입력할 수 있다. 이 이름은 그 작업에 관한 모든 보고에 표시된다.
* 작업 형태
- 상기 필드는 사용자에게 작업 형태의 목록을 제안한다. 각 작업형태는 사용자에게 의미가 있는 이름에 의하여 식별된다. 사용자는 목록으로부터 하나의 항목을 선택해야만 한다.
- 작업 형태는 작업구성으로서 메시지 분배 시스템의 데이터베이스에 표현된다. 각 작업 구성은 작업 레벨 정보 및 템플릿 파일과 템플릿 아티팩트(artifact) 파일의 수집을 포함하고, 템플릿 파일과 템플릿 아티팩트 파일은 메시지 분배 시스템 지원팀에 의하여 미리 마련되고, 데이터베이스 내에 시험되어 저장된다.
* 수신자 파일
- 초기에 사용자는 하나의 엔트리 필드('브라우저'단추 및 '업로드'단추와 연관됨)를 제공받는다.
- 수신자 파일을 지정하기 위하여, 사용자는 표시될 브라우즈 윈도를 생성하는 '브라우즈'단추를 클릭한다. 사용자가 필요한 파일을 선택하면, 파일 경로는 텍스트 엔트리 필드에 나타난다. 사용자가 '업로드'단추를 클릭하면, 그 파일은 메시지 분배 시스템으로 업로드되어 '업로드 파일'목록이 나타난다. 사용자는 사용자가 이와 같은 방식으로 원하는 만큼 많은 파일들을 업로드 할 수 있다.
- '업로드파일' 목록 옆에 있는 '삭제'단추는 선택된 업로드 파일을 삭제하는 데 이용된다.
- 메시지 분배 시스템의 엔터프라이즈 인터페이스는 다양한 포맷으로 수신자 파일을 수용한다. 수신자는 XML 포맷으로 변환되고 그 변환된 폼으로 데이터베이스에 유지된다.
* 작업 시작 시간
사용자는 작업 처리의 선택을 즉시 제안 받거나 이후의 날짜와 시간에 시작할 작업을 시간표 조정할 선택을 제안 받는다. '날짜' 필드는 미래의 30일까지의 선택을 제안한다. '시간'필드는 사용자가 시와 분으로 시작 시각을 서술하게 한다.
사용자는 작업을 제출하기 위하여 '제출'을 선택한다. 작업이 제출된 후에, 메시지 분배 시스템은 템플릿, 템플릿 아티팩트 및 데이터베이스에 있는, 서술된 작업 형태에 대응하는 다른 작업 정보를 위치시킨다. 그 다음에 그 시스템은 필요에 따라 수신자 파일들을 유효하게 한다. 이 유효화 과정 동안에 오류가 발생되는 경우에, 메시지분배 시스템은 오류가 있는 수신자의 상세한 정보를 표시한다. 그 다음에 사용자는 오류를 정정하고 그 작업을 다시 제출한다.
작업 상태 보고 뷰(view)
사용자가 작업이 제출된 후의 소정의 시각에 작업 상태 보고를 요구할 수 있다. 메시지 분배 시스템은 그 데이터베이스에 있는 정보로부터 작업의 현재 상태를 구하여 화면에 적당한 작업 상태 보고를 표시한다(사용자는 자신이 희망하면 이를 인쇄할 수도 있다).
도 20에 있는 실시예는 엔터프라이즈 인터페이스를 이용하여 제출된 청구서 분배 작업에 대한, 전체 작업 상태 보고 (2000) (즉, 4개의 옵션을 포함)을 나타내고 있다. 보고(2000)는 '인쇄하기에 적당한' 포맷(하얀 바탕에 검은색)으로 표시되고 새로운 브라우저 위도로 표시될 수 있다. 이 실시예에서, 메시지 분배 시스템 작업 ID는 '34656'이고 사용자에 의하여 할당된 작업 참조는 "청구서 3"이다.
그 작업은 계정 "Essential Mail"하에서 22:21에 제출되었고 그 작업 상태 보고는 4시간 31분 이후(다음날 새벽 2:52)에 생성되었으며, 그 작업은 여전히 '2차시도'상태('작업상태'로 표시되는 것과 같이)에 있다. 가능한 작업 상태의 종류에는 '시작되지 않은 처리,' '처리에서 시도1,' '처리에서 시도2,' '처리에서 시도3,' 및 '종료' 상태에 더하여 다양한 오류 상태들이 있다. 그 작업은 763 수신자를 지정하였고 엔터프라이즈 인터페이스를 통하여 제출되었다.
보고의 나머지는 그 보고가 생성된 시간에 메시지 전송 상태를 나타내고 있다. 정보는 다음 세 개의 범주로 분류된다.
* '마스터 메시지' 정보는 각 시도에 대하여 수신자 레코드에서 처음으로 지정되었던 전송과 관련이 있다. 마스터 메시지의 전송의 실패는 잠재적으로 방향변경(redirection)을 발생시킨다( 즉, 다음 시도를 일어나게 한다).
* '복사 메시지' 정보는 모든 다른 전송과 관련되고, 이는 방향변경(redirection)을 트리거하지 않는다.
* '개봉된 전자우편 첨부물'은 전자우편 첨부물의 개봉을 참조한 한다.
보고(2000)에서, 수신자 하나마다 763 마스트 메시지가 전송되었다. 12개의 전송이 실패하여 2차시도가 발생하였다. 763마스터 메시지 중에서 두 개가 실패하였다(지정된 방향변경(redirections)을 시도한 후에). 다른 4개는 여전히 진행중에 있다(즉, 4개의 메시지가 전송되었지만 전달 상태는 아직 결정되지 않았다). 94개의'복사' 메시지가 전송되었다. 물론, 89개가 성공적으로 전달되었으나 2개는 실패하였고 3개는 진행중에 있다.
보고의 두 번째 및 세 번째 부분은 각 개별적인 전송에 대한 상세 사항을 언급하고 있다. 각 전송상태는 다음과 같은 포맷으로 표현된다:
nn-mmm-hh:mmd
여기서,
* 'nn'은 다음과 같은 전송 상태를 나타낸다:
- 'OK'은 성공을 나타낸다.
- 'IP'는 진행중임을 나타낸다.
- 'NC'는 '미확인(not confirmed)'를 나나타낸다 (즉, OK라고 가정하지만 그 상태가 명확하게 확인될지 않음). 'NC' 상태는, 앞으로 설명할 것이지만, 전자우편의 특성이다.
- '두 자리'숫자는 발생된 오류를 나타낸다 (그 숫자는 실패 원인을 나타낸다)
* 'mmm'은 지정 매체를 나타낸다 (EML(전자우편), FAX(팩스), SMS (단문메시지) 또는 PAP(서신))
* 'hh:mm'은 전달 또는 비-전달 시각을 나타낸다(또는 SMS 및 서신에 대해서는, 캐리어로 전송한 시각을 나타냄).
* 'd'는 윗첨자로서, 메시지가 후일에 전달(전달이 실패함)되는 경우에만 포함된다. 숫자'1'은 다음 날을 나타내고, 숫자 '2'는 그 다음날을 나타내는 방식으로 계속된다.
'마스터 메시지' 부분에서, 마스터 메시지 전송이 실패(여러 차례 시도 후의 실패)하거나 여전히 '진행중'인 상태를 갖는 모든 수신자들은 보고의 전면에 그룹지어진다. '복사 메시지'부분에서, 수신자는 같은 순서로 정렬된다. 보고의 마직막 부분은 전자우편 첨부물이 개봉된 시각들을 나타낸다. 각 첨부물은 'Xn'에 의하여 식별되고, 'n'은 그 부분(section)의 시작 부분에서 레전드에 있는 첨부물을 식별하는 번호를 나타낸다. 상기 보고 (2000)는 단순히 예에 불과하고, 본 발명의 범위와 사상을 벗어나지 않고 많은 변형예가 있을 수 있으리라고 당업자는 쉽게 알 수 있을 것이다.
작업 구성(통제 사용자들에 대해서만)
도 21A 와 도 21B의 작업구성 패널(2100)은 사용자들을 통제사용자들에게 유용하고, 작업 구성에 대응하는 메시지 분배 시스템의 데이터베이스에 있는 레코드 클러스터를 부가, 변경 및 삭제하는 데에 이용된다. 엔터프라이즈 인터페이스 작업을 위한 작업 구성만이 접근될 수 있다.
'작업 구성' 주메뉴 옵션이 선택된 후, 선택 패널은 사용자에게 기존의 작업 구성을 선택할 선택권(choice)을 제공하거나 새로운 작업 구성을 생성하는 선택권(choice)을 제공한다. 상기 패널이 종료된 다음에, 주작업 구성 패널(2100)이 표시된다.
도21A와 도21B의 패널(2100)은 지정된 작업 구성에 대하여 상세한 사항 전부를 나타낸다. 정보는 수평선들에 의하여 나뉘어진 복수개의 부분들로서 포맷된다. 각 부분은 작업 구성 레코드 클러스터에 있는 하나의 레코드를 나타낸다. 나타낸 실시예에서, 직업 구성은 JAVA_MAPPING_CLASS 레코드, JAVA_MAPPING_CLASS_RESORUEE 레코드, CONFIG_DATA 레코드, TEMPLATE 레코드, 두개의 TEMPLATE_ARTIFACT 레코드를 포함한다.
각 부분은 파일의 파일이름을 나타내고, 그 파일이름은 그 레코드와 그 레코드의 다른 필드의 값으로 입력된다. 사용자는 '불어오기(import)'단추 옆에 있는'브라우즈'단추(사용자가 파일을 입력하기 위하여 선택할 수 있는 '브라우즈' 윈도를 생성함)를 이용하여 새로운 파일들(기존의 파일들을 대체함)을 입력한다. 또는, 사용자는 '삭제'단추를 사용하여 전체 부분을 삭제할 수 있다(즉, 관련된 레코드를 삭제함).
반복할 수 있는 부분들에 대하여, '새로운 ... 레코드 추가' 단추는 다른 빈 부분에 제공된다.
패널의 밑의 부분은, 지명된 파일에 대한 ZIP 저장으로서, 클러스터 내의 파일을 내보내게 한다. 파일은 메시지 분배 시스템 서버의 지정된 디렉토리(예를 들어, 'C:|JobConfigurations') 내에 저장되고, 자동적으로 생성된 이름을 갖으며, 이 이름은 고객이름, 작업 구성 표시 이름 (예를 들어, 작업 형태) 및 날짜와 연관된다. 변경은 사용자가 '제출'단추를 누름으로써 이루어진다. 삭제 단추는 필요하다면 전체 클러스터를 삭제하게 한다.
IV. FTP 인터페이스
경우에 따라, 고객들은 그들의 엔터프라이즈 인터페이스로부터 수신자 파일을 생성하여 분배를 위한 메시지 분배 시스템에게 그 파일을 자동적으로 전송한다(즉, 사람의 간섭없이). 이와 같은 상황에서, 웹인터페이스는 그들의 필요에 적절하지 않을 수 있다. 따라서 메시지 분배 시스템은 '엔터프라이즈 인터페이스' 스타일 작업이 FTP 전송을 통하여 인터넷으로 제출되게 한다. FTP 전송은 작업 제출( 및 그와 관련됨) 화면을 대신한다. 고객, 사용자 및 계정 레코드는 FTP 전송 중에 정확하게 설정되어야만 한다.
FTP 작업이 제출된 후에, 사용자는 작업 진행을 감시하기 위하여 정상적인 메시지 분배 시스템 설비(facilities)를 이용한다 (즉, 작업 상태 보고의 검사).
FTP 인터페이스를 통하여 작업을 제출하기 위하여, 사용자는 FTP 클라이언트 프로그램을 이용하여 인터넷을 통하여 단일 ZIP 파일을 메시지 분배 시스템으로 전송한다. 전송 처리절차는 SSL 보안을 이용하여 수행되고 사용자가 FTP '사용자 ID' (이는 'cccc-uuuu'폼으로 되어 있고, 'ccccc'는 사용자의 메시지 분배 시스템 고객 ID를 나타내고 'uuuuu'는 사용자의 메시지 분배 시스템의 사용자 ID를 나타냄)와 FTP '비밀번호'(이는 사용자의 메시지 분배 시스템 사용자 비밀번호와 같음)를 입력할 것을 요구한다.
ZIP 파일은 다음과 같은 파일을 포함한다:
* 'jobcontrol.xml'이라는 작업 제어 파일
* 하나 또는 그 이상의 수신자 파일, 그 수신자 파일의 이름은 작업 제어 파일에 언급되어 있음(수신자 파일 참조)
작업 제어 파일(jobcontrol.xml) (2200)의 포맷은 도 22에 나타나 있다. 그 파일에 있는 대부분의 필드는 웹인터페이스의 등가물의 복사본이 된다. 시험 속성은 그 시험 속성이 시험 작업인지 아닌지를 지정한다. 고객들이 '상태보고' 화면 다음에 작업을 식별하기 위하여 고객들은 유일한 '작업-참조'를 지정한다.
V. 시스템 아키텍쳐
메시지 분배 시스템의 내부 아키텍쳐는 다음에서 설명되고, 이는 메시지 분배 시스템을 통한 주요 처리 절차 흐름의 선택을 포함한다. J2EE와 자바 웹 콘테이너의 전반적인 지식이 요구되지만, 다른 설명을 이해하는 데에는 반드시 필수적이지는 않다. 때때로 이 부분은 데이터베이스에 있는 표(또는 '레코드 형태')를 참조한다. 이들 이름은 윗첨자로 인쇄된다. 레코드의 기능과 구조의 상세한 설명은 VII절에 포함된다.
도23은 메시지 방송 시스템 (2400)의 아키텍쳐를 나타낸 구성도이다. 상기 시스템(2400)은 프론트 엔드 (2410)와 백엔드(2420)를 포함한다. 사용자(2402)는 모듈(2412)을 사용하여 작업 상태 보고를 검색할 수 있고, 표준 인터페이스(2414)를 이용하여 하나의 작업을 제출할 수 있으며, 모든 프론트 엔드 (2410)에 있는 엔터프라이즈 인터페이스(2416)를 이용하여 하나의 작업을 제출할 수 있다. FTP 파일 (2404)은 엔터프라이즈 인터페이스(2412)에 제공될 수 있다.
표준 인터페이스 (2414)에서, 작업정보는 사용자(2402)로부터 수신되고 수신자 목록과 템플릿이 업로딩된다. '유효화'는 수신자 목록을 검토하기 위하여 유발된다. 제출 요구는 사용자로부터 수신되고, '제출'과정은 유발된다.
표준 인터페이스(2414)로부터, 백엔드(2420)의 표준 작업 제출 프로세션(2424)은 입력 데이터를 유효하게 하거나 점검하고 그 작업을 제출한다. 이는 수신자 목록을 XML 로 변환하는 과정과 작업 큐에 작업을 저장하는 과정과 관련된다. 그 다음에 처리절차는 플럭스 모듈 (2432)에서 계속된다.
엔터프라이즈 인터페이스는 사용자(2402)로부터 작업 정보를 수신하여 그 수신자 목록을 업로딩한다. 수신자 목록은 유효화 처리를 유발함으로써 점검된다. 제출 요청은 사용자로부터 수신되고, 그 요청을 처리하기 위하여 제출이 유발된다. 인터페이스 (2416)로부터 처리절차는 엔터프라이즈 작업 제출 처리기(2426)에서 계속된다. 이는 입력 데이터를 점검함으로써 수신자 목록을 유효화시키고, 제출 처리를 동작시킨다. 이는 수시자 목록을 XML 로 변환하여 작업큐에 작업을 저장한다. 그 다음에 처리절차는 플럭스 (2432)에서 계속된다. 처리기(2424 및 2426)의 출력은 하나의 이벤트가 된다. 그 다음에 활동(actions)은 플럭스 (2432)로부터 발생한다.
활동은 번들 처리기(2450)로 진행한다. 모듈 (2452)은 각 매체형태를 위하여 하나의 전송 번들을 형성하고 그 다음에 각 전송 번들을 위하여 처리 번들 쓰레드(a, b, c 및 d)를 기동시킨다. 이들 쓰레드는 A, B, C 및 D로 나타내지고, 각각은 모듈 (2454, 2456, 2458 및 2460)과 연결된다. 각 모듈 (2454, 2456, 2458 및 2460)은 서로 비슷한 포맷을 갖는다. 예를 들어, 팩스 전송 번들(2454)은 병합 동작, 포맷 동작 및 전송 동작과 관련된다. 서신 전종 번들(2456), SMS 전송 번들(2458) 및 전자우편 번들 (2460)은 비슷한 배열구조를 갖는다. 각 번들 모듈의 출력은 각각의 캐리어, 예를 들어, 엑스페다잇(expedite) (2462), EDI 포스트 (2464), SMS 도달 (2466) 및 메시지 도달 (2468)로 제공된다. 각 캐리어는 백엔드 (2420)로 상태보고 백을 제공한다. 엑스페다잇(expedite)(2462)는 팩스 상태보고(2442)를 제공하고, EID 포스트 (2464)는 서신 상태 보고 (2440)를 제공하고, SMS 도달(2466)은 SMS 상태 보고(2438)를 제공하며 메시지 도달 (2468)은 전자우편 상태 보고(2436)를 제공한다.
전자우편 상태 보고(2436), SMS 상태보고 (2438), 서신상태보고(2440) 및 팩스상태보고(2442)는 상태 수집기 모듈 (2434)로 제공된다. 상기 모듈(2434)은 주기적으로 팩스(2432)에 의하여 유발된다. 이는 캐리어들에 의하여 제공되는 상태 정보를 검색하여 이를 작업큐에 인가한다. 작업큐(2430)는 작업과 템플릿 정보, 수신자 정보 및 상태정보를 갖는다. 작업큐(2430)는 과금 기록을 회계 시스템(2460)에 제공할 수 있고 상태정보를 번들 처리기(2450)에 갱신할 수 있다. 작업 큐(2430)는 출력을 상태 보고 모듈(2422)로 제공하고, 이는 바람직하게는 XML 자료로서 상태정보를 검색한다. 상태 보고 모듈 (2422)은 프론트 엔드(2410)에서 모듈(2412)에 의하여 검색되는 작업 상태 보고를 제공한다. 사용자 (2402)는, XSL 스타일 시트를 이용하여 포맷된 XML 상태 보고를 검색할 수 있고, 이를 인쇄하기에 양호한 포맷으로 표시한다. 이들 포맷과 다른 상세한 사항들은 다음에서 설명된다.
작업큐
작업큐(2430)는 메시지 분배 시스템(2400)의 주요 성분이다. 그 작업큐(2430)는 모든 메시지 분배 시스템 작업의 상세한 사항을 포함하고, 그 메시지 분배 시스템은 현재 동작하고 있거나, 동작을 대기하고 있거나 동작이 완료된 상태에 있다. 각 작업은 데이터메이스에서 다양한 형태의 레코드의 클러스터에 의하여 표현된다. 각 클러스트는 JOB 레코드가 헤드에 있다. 상기 레코드는 작업 자체, 이용된 템필릿, 메시지가 전송된 수신자, 병합 필드, 및 목적지에 대한 상세한 사항들을 포함한다.
정상적인 동작 중에, 메시지 분배 시스템(2400)은 미리 결정된 시간 (예를 들어, 매분마다) 작업큐(2430)를 스캔하여 동작하고 있거나 그 동작이 완료된 모든 작업들에 대한 상세한 사항들을 추출한다. '콘솔' 패널을 표시하는, 소정의 메시지 분배 시스템 지원팀 브라우저들이 상기 데이터 추출에 접근하여 그 시스템에 있는 작업들의 현재 상태를 표시하도록 구해진 데이터를 이용한다. 이와 같은 방식으로, 메시지 분배 시스템 지원팀은 작업큐(2430)의 최신 개요를 갖는다.
상기 지원팀은 하나의 작업의 처리 과정에 영향을 주기 위하여 '작업 통제'패널에 의하여 제공되는 기능을 이용한다(예를 들어, 잘못된 작업을 복구, 전송 번들 파일을 재전송, 등). 따라서, 작업큐는 통제의 중심점을 제공하고, 이는 시스템(2400)에 처리 부하를 완화하고, 고객 요청에 대하여 반복적으로 반응하며 스크래치로부터 사용자의 작업을 다시 배출할 필요없이 예상하지 못했던 문제를 고치기 위하여 이용될 수 있다.
하나의 작업은 가능한 한 빠르게 그 작업이 유효화되고 처리기 (2424 또는 2426)를 통하여 사용자에 의하여 제출될수록 작업큐(2430)에 위치된다. 상기 작업은 그 작업이 종결되고 그 다음에 소정의 시간동안 작업큐(2430)에 남아 있게 된다(사용자에게 그 작업에 의해서 생성된 작업 상태 보고(2422)를 검사할 시간을 준주기 위하여). 이는 '쓰레기 수집(garbage collection)'과정에 의하여 이후에 제거될 수 있다.
작업처리단계
도 23은 메시지 분배 시스템의 높은 수준의 아키텍쳐(2400)를 나타낸 구성도이다. 큰 상자(2400)는 메시지 분배 시스템 자체를 표시한다. 데이터 구조는 모듈들(2434, 2436, 2438, 2440,2442, 2454, 2456, 2458 및 2460)이고 외부 엔터티들은 모듈들(2402, 2404, 2460, 2462, 2464, 2466, 및 2468)이 된다. 처리기들은 모듈들 (2412, 2414 및 2416)(서브릿(servlets) 및 JSPs)과 모듈들 (2422, 2424, 2426, 2435, 및 2450)(세션 빈(session beans))로 표현된다.
상기 시스템(2400)은 기본적으로 두 개의 부분, 즉 프론트 엔드(front end) (2410) 및 백엔드(back end)(2420)로 나뉘어져 있고, 작업큐(2430)는 이들 사이에서 '브리지(bridge)'역할을 한다.
* 프론트엔드 로직(2410)은 톰캣 콘테이너에서 동작하는 자바 'JSPs'와' 서브릿(servlets)'에 의하여 공급될 수 있다.
* 백엔드 (2420)는 JBoss 콘테이너에서 동작하는 자바 EJB '세션빈즈'(이는 차례대로 EJB '엔터티 빈즈'와 다른 자바 객체들을 이용한다).
프론트엔드는 직접적으로 데이터베이스에 접근하지 않지만 대신에 그렇게 접근하기 위하여 백엔드 (2420)에서 세션빈즈를 유발한다.
프론트 엔드
메시지 분배 시스템 프론트 엔드 (2410)는 사용자 인터페이스를 다루는 것과 관련된 로직을 포함한다. 프론트 엔드 (2410)는 빠른 응답을 사용자 (2402)에 제공하고 그래서 긴 처리 태스크가 프론트 엔드(2410)로부터 배출될(excluded) 수 있게 한다.
프론트엔드의 주요 기능은 사용자들 (2414, 2416)이 제공하는 작업을 수신하는 것과 작업 큐(2430)에서 처리를 대기하기 위하여 이들을 위치시키는 것이다. 구성도에서는 더 중요한 3개의 프론트 엔드 처리들(2412, 2414, 2416)이 나타나 있다.
* 엔터프라이즈 인터페이스(2416)를 통하여 하나의 작업 제출
* 표준 인터페이스(2414)를 통하여 하나의 작업 제출
* 작업 상태 보고(2412)를 요청
다른 프론트엔드 처리들이 있지만, 간단하게 하기 위하여, 그러한 처리들은 도23에 포함시키지 않았다.
각 '프론트엔드' 처리(서브릿과 JSPs의 합성물(mixture)을 포함)는 대응하는 '백엔드' 세션빈을 가지고 있고, 이는 모든 데이터베이스 검색과 갱신을 수행한다. 데이터베이스 접근/잠금 중요성을 자유롭게 함으로써, 프론트엔드(2410)는 양호한 상호작용 응답을 제공한다.
플럭스
프론트엔드(2410)가 작업큐(2430)에 하나의 작업을 위치시킬 때마다, '프론트엔드'(또는, 더 정확하게는, 프론트엔드 세션빈 )는 플럭스 이벤트(2432)를 트리거한다. 플럭스는 SIMS 소프트웨어사에서 제공하는 일종의 스케줄링 툴이다. 메시지 분배 시스템(2400)이 활성되어 있기만 하면, 스케줄링 툴은, 자바 가상 머신에서 독립적인 처리로서, 계속해서 동작한다. 상기 툴은 메시지 분배 시스템 데이터베이스 내에 자신의 정보 표들을 유지한다. 이들 표는 플러스(2432)에 의하여 전체적으로 관리된다. 플러스 모듈 (2432)은 타이머에 의하여 또는 다른 처리에 의하여 트리거되는 이벤트에 대응하여 각각에 대하여 미리 결정된 행동을 수행한다. 예를 들어, 새로운 작업이 작업큐에 위치되면, 프로트엔드 세션은 트리거될 플럭스(2432)에 대하여 즉시(도는 사용자가 이후에 동작될 하나의 작업에 대하여 시간조절을 한다면 가까운 미래에) 이벤트를 정의한다. 그 이벤트가 트리거되면, 플러스 (2432)는 그 이벤트를 다루기 위하여 '백엔드'(2430)에 세션빈을 유발한다.
백엔드
'백엔드'(2420)는 세션빈즈 셋을 포함하고, 이는 프론트 엔드 처리들에 대한 '도움자(helpes)'로 행동한다. 백엔드 세션빈은 데이터베이스 처리 동작들을 수행하고, 이들은 프론트 엔드 성분들을 요구한다. 예를 들어,
* EnterpriseJobSubMissionProcessorBean.java 는 엔터프라이즈 작업 제출 인터페이스를 수행하는 서브릿과 JSPs를 위하여 데이터베이스 동작을 수행한다.
* StatusReportBean.java는 '작업상태보고'기능을 수행한 서브릿과 JSPs에 의한 사용을 위하여 데이터베이스로부터 상태 보고 정보를 수집한다.
* AccountBean.java는 계정 유지 패널을 수행하는 서브릿 및 JSPs를 대신하여 ACCOUNT 레코드에서 데이터베이스 I/O를 수행한다.
백엔드(2420)는 메시지 분배 시스템(2400)의 '실제작업(real work),'즉, 작업큐(2430)로부터 구해진 작업의 처리들을 수행하는 세션빈즈를 포함한다. 하나의 작업의 처리는 넓게 다음 항목들을 처리한다:
1. 메시지 분배 시스템(2400)은 작업에 있는 모든 RECIPIENT 레코드를 스캔하고, 각각에 대하여 제1 ATTEMPT 레코드에 연결된 TRANSMISSION 레코드를 식별한다. 이들 각각의 레코드는 메시지가 제1 시도의 일부로서 전송될 하나의 목적지를 나타낸다. 그런 다음에 메시지 분배 시스템 (2400)은 메모리에 여러 전송 번들(2454, 2456, 2458, 2460)(때때로 '전송 패킷번들'이라고 알려져 있음)을 생성한다. 목적지 매체(즉, 팩스를 위한 매체, 전자우편을 위한 매체, 등)마다 하나의 전송번들 (2454, 2456, 2458, 2460)이 있고, 각각은 여러 전송 패킷들을 포함한다. 각 전송 패킷은 그 매체를 지향하는 '제1 시도'목적지를 갖는 하나의 수신자에 대하여 정보를 포함한다.
따라서, 예를 들어, 특정 RECIPIENT 레코드는 제1'시도'에 팩스와 전자우편에 대한'전송'을 지정하다면, 수신자의 상세한 사항의 복사본은 팩스 전송 번들과 전자우편 전송 번들에 나탄난다.
2. 전송 번들은 다른 처리 쓰레드에서 병렬로 처리된다. 각 전송 번들은 세단계로 처리된다.
병합 단계 - 수신자 레코드로부터 병합값들이 그 매체를 위하여 템플릿(들)에 있는 적당한 병합 필드들로 대체된다. 따라서, 각 수신자를 위하여 전적으로 병합된 메시지가 생성된다.
포맷 단계 - 번들에 있는 각 메시지는, 필요에 따라, 적당한 출력 포맷으로(예를 들어, 팩스용 TIFF) 다시 포맷된다.
전송 단계 - 각 전송 번들은 디스크 파일로 작성되고, 그 목적지로 가는 전방 전송을 위한 캐리어로 전송된다.
3. 메시지 분배 시스템 (2400)은 캐리어에 의하여 제공되는 캐리어 상태 보고를 대기한다. 각 캐리어 (2462, 2464, 2466, 2468)는 수신된 각 건송 번들을 위하여 캐리어 상태 보고를 생성한다. 그 보고(2436, 2438, 2440, 2442)는 하나의 수신자에 대한 메시지의 각 개별적인 전송의 결과를 가리킨다. 캐리어 상태 보고의 검색은 상태수집(2434)으로 알려져 있다.
4. 메시지 분배 시스템 (2400)은 작업큐(2430)(TRANSMISSION 레코드에 유지됨)에 있는 수신자 상태 정보를 갱신하기 위하여 다양한 캐리어 보고 (2436, 2438, 2440, 2442)에 있는 정보를 이용한다. 상기 정보는 성공/실패 코드, 종결된 시간 전송, 전송된 페이지/바이트 수, 등을 포함한다.
일단 제1 '시도'를 위한 모든 다양한 캐리어 상태 보고가 수신되어 작업큐(2430)에 위치되면, 메시지 분배 시스템 (2400)은 작업큐(2430)에 있는 수신자 데이터를 다시 스캔한다. 제1 시도의 마스터(즉, 제1) 전송이 실패한 소정의 수신자가 있다면, 그 작업은 '제2시도' 전송을 이용하여 메시지 분배 시스템 (2400)(상기 단계 1~4를 반복함으로써)에 의하여 다시 처리된다. 상기 제2시도들 중에 마스터 전송이 실패하면, 그 처리는 제3시도전송을 위하여 한 번 더 반복된다.
하나의 작업이 처리되는 동안 또는 처리된 다음의 어느 시점에서, 고객은 강화된'작업 상태 보고'를 요청한다. 이는 작업의 상세한 사항의 완전한 정리, 수신자의 수 및 시간 내의 그 순간에 전송된 각 매시지의 최후의 상태를 생성한다. 선택적으로, 그 작업이 종결될 때 사용자에게 자동적으로 전자우편이 전송된 보고를 그 사용자는 가질 수 있다. 이와 같은 옵션은 계정 레코드에서 지시된다. 메시지 분배 시스템은 각 전송 시도(즉, 페이지 수, 전송된 바이트 수, 성공/실패 상태, 등)에 대하여 전적으로 상세한 사항들을 포함하는 과금 기록의 셋(하나의 수신자에 대한 각 시도된 전송을 위한 레코드)을 생성하고, 이들을 회계 시스템으로 전송하고, 여기서 그 레코드는 고객에게 청구하기 위하여 사용된다.
VI. 데이터 파일 구조
메시지 분배 시스템에 의하여 사용된 여러 데이터 파일의 포맷은 아래에서 상세하게 설명된다.
템플릿 파일
템플릿 파일은 여러 범위의 포맷으로 제공될 수 있고, 이는 두 그룹으로 나뉠 수 있다. 즉, 병합필드를 포함할 수 있는 그룹과 병합필드를 포함하지 않는 그룹이다.
병합필드를 포함할 수 있는 그룹은 XML 스타일시트(XSL) 파일, MS 워드(DOC) 파일 및 간단한 텍스트 (TXT) 파일을 포함한다.
* XML 스타일시트(XSL) 파일
- XML 스타일시트는 일종의 파일로서, XML 기호로 표현된다. 이는 소정의 자료(텍스트, 이미지, 여백, 헤더, 끝부분, 다른 아티팩트(artifact))의 포맷을 정확하게 설명한다. 또한 그 파일은 '병합필드'를 위한 프로비전을 포함한다. 사용자 파일(XML 포맷으로)을 스캔닝하고, 수신자 '병합값'을 추출하고, 추출된 값을 XSL 스타일시트와 조합하며 각 수신자를 위한 출력 자료(XSL:FO로 알려진 포맷으로)를 생성하는 처리는 Xalan(아파치(Apache)사에서 공급함)이라고 불려지는 소프트웨어 제품에 의하여 수행된다. XSL 및 XSL:FO 의 상세한 사항은 자료에서 찾아볼 수 있다: 확장가능한 스타일시트 언어(Extensible Stylesheet Language(XSL), 버전 1.0, W3C 권고안에 따라, 2001. 10. 15에 월드와이드웹 컨소시엄에서 공개되었으며 에서 이용할 수 있다.
* MS 워드(DOC) 파일
- DOC 파일은 MS 워드의 워드 처리기에 의해서 생성된다. '병합필드'는 소정의 자료에서 정의될 수 있고 워드 표준 '병합'편의성을 이용하여 '병합값'으로 교체될 수 있다. 메시지 분배 시스템에서, DCO 템플릿의 병합은 MS 워드 자체에 의하여 수행될 수 있다. MS 워드는 윈도 2000(즉, 자바 가상 머신 외부에서)의 제어하에서 직접적으로 하나의 컴퓨터에서 단독으로 실행 가능한 프로그램으로서 동작한다. 메시지 분배 시스템은 워드(즉, 템플릿과 수신자파일을 메시지 분배 시스템으로 건네주고 병합된 결과를 수신함)와 상호작용하기 위하여 MS사의 DCOM 편리성을 이용할 수 있다.
* 텍스트 (TXT) 파일
- 텍스트 파일은 아스키(ASCII) 텍스트의 단순한 문자열로서, 이는 선택적으로 병합 필드를 포함한다. 적당한 경우에, '줄의 끝(end of line)'문자(즉, <CR> 및 <LF>)는 허용되지만 다른 포맷팅 문자는 허용되지 않는다.
병합필드를 포함하지 않는 템플릿의 형태는 다음을 포함한다:
* TIFF(TIF) 파일
TIFF파일은 비트맵 그래픽 폼의 이미지를 포함한다.
* 어도비 아크로벳 자료 (Adobe Acrobat Document File (PDF))파일
상기 파일의 포맷은 어도비사에 의해서 공개된다.
* 포스트크립트(PRN) 파일
포스트크립트 파일은 여러 프린터들을 구동하기 위하여 특별하게 설계된다(그리고 종이를 지정하기 위한 출력을 생성하기 위하여 메시지 분배 시스템에 의하여 사용될 수 있음). 사용자는 워드프로세서에 텍스트와 다른 정보를 입력하고, 물리적 인쇄기라기보다는 프린터 파일(이는 기본적으로 PRN 파일 형태임)로 그 파일을 출력함으로써 포스트크립트 파일을 정상적으로 처리한다.
* HTML (HTM) 파일
HTML 파일은 HTML 마크업 언어로 포맷된 정보를 포함한다.
수신자 파일
엔터프라이즈 인터페이스 (2416)의 사용자는 다양한 형태의 포맷으로 메시지 분배 시스템(2400)으로 파일을 제출하고, 반면에 표준 인터페이스 (2414)의 사용자들은 바람직하게는 '콤마 분리 값(comma separated values(CSV)') 포맷으로 이들을 제출한다. 특별한 자바 클래스 (데이터 변환기의 일부분으로서)는, 제출된 파일을 작업큐(2430)(메시지 분배 시스템 데이터베이스에 있음)에 위치시키기 전에, 그 제출된 파일을 모듈(2424 또는 2426)에 있는 XML 포맷으로 변환하기 위하여 이용된다. 상기 클래스는 데이터베이스에서 유지되는 작업 구성 내에서 JAVA_MAPPING_CLASS레코드에서 유지된다. 상기 자바 매핑 클래스는 매핑 처리에서 도움을 주기 위한 다른 아티팩트를 이용한다. 이는 다른 자바 클래스, XFlat 매핑 파일, 및 XSL 스타일시트를 포함한다. 이들 아티팩트는 데이터베이스에서 유지되는 작업 구성 내에서 JAVA_MAPPING_CLASS_RESOURCE레코드에서 유지된다.
XFlat 매핑 파일은 스테이트먼드의 셋(XFlat으로 알려진 포맷 변환 정의 언으로 표현됨)으로서, 이는 'XML 변환기 유틸리티'에 제공될 수 있다. XML 변환기 유틸리티는 다양한 범위의 간단한 포맷의 변환을 다룬다.
XML 파일
XML 포맷의 수신자 파일은 복수의 <수신자>요소들을 포함하고, 수신자마다 하나의 요소들이 할당된다. 상기와 같은 파일(250))의 예(하나의 수신자만을 포함함)는 도 24에 나타나 있다. 상기 실시예의 데이터를 간단하게 설명하면 다음과 같다.
* 개인 상세정보
'<개인-상세정보>'요소는 수신자의 경칭, 이름 및 성을 표시하는 서브-요소들을 포함한다. 이들은 팩스의 '띠주소(strip address)'(팩스가 수신자에게 전송되는 경우에)내에 사용되고, 우편 주소의 첫 번째 줄로서 사용된다(서신우편이 수신자에게 전송되는 경우). 선택적 '<참조>'요소는 이용될 수 있고, 이는 메시지 분배 시스템에 의하여 생성되는 작업 상태 보고에 나타나는, 사용자-특정 텍스트의 10개 문자까지 포함할 수 있다. 통상적으로, 전송자는 그에게 의미가 있는 소정의 이름(예를 들어, 고용인의 번호, 은행계좌번호, 건강보험증의 번호, 등)을 통하여 수신자를 식별하기 위한 상기 요소를 이용한다.
* 지정 설정
'<지정-설정>'요소는 수신자를 위하여 사용된 지정을 설명하고, 실패할 경우에 유발될 방향변경(redirection) 옵션을 위하여 설명한다. 상기 요소는 하나의 '<시도>'서브 요소, 두 개의 '<시도>'서브-요소, 또는 세 개의 '<시도>'서브-요소를 포함한다. 각각의 '<시도>'서브-요소는, 공백 또는 콤마에 의하여 분리되는 하나의 전송, 두개의 전송 또는 세 개의 전송을 설명한다. 각 '전송'은 '<지정>'필드에 있는 'id'속성에 대응하고 그에 따라 특정한 지정을 표시한다. 설명된 제1전송은 '마스터'가 된다. 팩스의 경우에, 각'전송'은 3번의 재시도까지 포함한다.
* 지정
하나의 '<지정>'요소는 각 매체 형태에 대하여 허용될 수 있다('매체'속성에 의하여 표시된 것과 같이). 특정한 매체에 제공되는 어떠한 요소도 없다면, 이는 수신자가 그 매체에 의하여 접근할 수 없음을 의미한다. 'id'속성은 '이전에 설명한 '<시도>'요소에 연결된 링크로서 이용되고, 그 어떠한 편리한 식별자를 포함할 수 있다. '<지정>'요소의 서브-요소들은 실질적인 지정 자체를 설명한다.
서신 주소의 두 개의 형태가 허용된다. 도 24는 분석된 폼을 나타내고 있다. 분석되지 않은 주소는 그 요소들을 이용하여 입력될 수 있다:
* <address-line-1></address-line-1>
<address-line-2></address-line-2>
... ...
<address-line-6></address-line-6>
* 수신자 데이터
'<수신자-데이터>'요소는 병합 필드를 포함한다. 상기 실시예에서, 하나의 청구서에는 단일 라인을 나타내는 하나의 병합 필드가 있고, 이는 그 라인 내에 정보의 항목들을 나타내는 여러 서브-병합-필드를 포함한다. 그러나 상기 실시예는 간단한 예에 불과하다. '<수신자-데이터>'필드는 포맷의 완전한 자유를 허용한다(양호한 폼으로 형성된 XML이 포함된다면).
VII. 데이터베이스 구조
메시지 분배 시스템 데이터베이스는 다양한 표를 포함한다. 도 25는 엔터티 관계 구성도(2600)로서, 표들과 이들의 관계를 보여주고 있다. 도25에서, 데이터베이스 표들 사이의 '다대일' 대응은 관계의 '많은'측면에서 '까마귀 발(crow feet)' 로 표현된다.
각 표('레코드'또는 '엔터티'와 같이 다양하게 표현됨)와 그 표에 있는 칼럼(때때로 '필드'로 표현됨)에 대하여 설명된다. 각 표는 유일한 주요키(primary key)를 포함하고, 이는 바람직하게 'xxxx_PK'('xxxx'는 표의 명칭을 나타냄)로 이름이 붙여진다. 상기 키(key)는 데이터베이스 복사 원인을 필요로 하고, 보통은 자동적으로 생성된다.
고객, 계정 및 사용자들
메시지 분배 시스템은 고객, 계정, 과금 선호와 관련된 정보를 가진다. 메시지 분배 시스템은 상기 정보의 서브-셋만을 필요로 한다. 이와 같은 이유로 인하여, 고객은 그들의 계정과 과금 선호를 직접 통제할 수 있도록 그 고객은 직접 온라인으로 과금 시스템으로 접근할 수 있다 (메시지 분배 시스템 서브셋은 필요에 따라 메시지 분배 시스템으로 내려받기(downloaded)를 할 수 있다).
데이터는 메시지 분배 시스템과 과금 시스템 사이에서 수동적으로 복사될 수 있다. 그렇게 되면, 메시지 분배 시스템 내에 유지되는 데이터의 양은 최소한으로 유지된다. 메시지 분배 시스템은 고객-관련 정보를 세 개의 주요 엔터티들로서 저장한다. 그 세 개의 엔터티들은 고객들 (2610), 사용자들 (2612) 및 계정들 (2614)을 포함한다. 각 고객은 그 자신의 사용자들과 계정들을 소유하고 관리한다. 데이터베이스 표들과 각 필드를 설명하면 다음과 같다.
고객
상기 표(2610)는 고객을 나타내고, 데이터베이스에서 '앵커 포인트(anchor point)'가 되며, 그 앵커 포인트에 모든 다른 엔터티들이 연결된다.
customer_PK: 자동적으로 생성된, 유일한 주요키이다.
id: 고객 식별자를 나타낸다. n-문자(n은 8이 될 수 있음) 식별자는 유일하게 고객을 식별한다. 각각의 고객 사용자는 사용자가 메시지 분배 시스템에 로그온할 때 고객 id를 입력한다.
name: 고객의 이름(예를 들어, ABC 은행 회사)을 나타낸다. 상기 필드는 고객과 관련된 다양한 화면과 보고에 나타난다.
timezone_code: 고객이 거주하는 곳의 시간대를 식별한다.
enabled: 고객이 활성화되었는지 비활성되었는지를 나타내는 블리언 프래그를 나타낸다. 비활성된 고객은 메시지 분배 시스템에 접근할 수 없다 (즉, 어느 고객의 사용자도 로그온할 수 없다).
enabled_change_time: 'enabled' 플래그가 지속적으로 변화되는 경우에 날짜/시간을 나타낸다. 한 동안 비활성 상태에 있는 고객은 데이터베이스에서 삭제된다.
ftpJobSubmission: 상기 고객이 FTP를 통하여 작업을 제출할 경우에 '참'이라고 설정한다.
사용자
사용자 레코드(2612)는 하나의 사용자(즉, 메시지 분배 시스템에 접근하는 사람)에 대하여 정보를 포함한다. 데이터베이스에서 상기 표의 실제 이름은 'USER_'가 된다. 트레일링 밑줄 문자(trailing underscore character)는 SQL 예약된 단어 '사용자'와 충돌을 피하기 위하여 추가된다.
user_PK: 자동적으로 생성된, 유일한 주요키이다.
id: 고객 식별자를 나타낸다. n-문자(n은 8이 될 수 있음) 식별자는 유일하게 고객을 식별한다. 사용자가 메시지 분배 시스템에 로그온하려면 사용자는 사용자 id를 입력해야 한다.
name: 사용자 이름 (예를 들어, 마리 스미스(Mary Smith))을 나타낸다. 상기 필드는 사용자와 관련된 다양한 화면과 보고에 나타난다.
password: 사용자의 비밀번호를 나타내고, 이를 로그온할 때 입력해야 한다.
customer_FK: 사용자를 '소유하는' 고객에 연결된 링크를 나타낸다.
email, phone_number, fax_number, mobile_number: 이들 필드들은 사용자를 위한 연락 정보를 포함한다(메시지 분배 시스템 지원팀이 필요하다면 사용자와 연락할 수 있도록 하기 위함).
test_email, test_fax_number, test_sms_number:상기 필드는 시험 작업을 위한 지정으로서 사용되기 위하여 사용자의 전자우편 주소, 팩스 번호 및 SMS 전화번호를 포함한다.
enabled: 사용자가 활성화되었는지 비활성되었는지를 나타내는 블리언 플래그를 나타낸다. 비활성된 사용자는 메시지 분배 시스템에 접근할 수 없다.
enabled_change_time: 'enabled' 플래그가 지속적으로 변화되는 경우에 날짜/시간을 나타낸다. 한 동안 비활성 상태에 있는 사용자는 데이터베이스에서 삭제된다.
administrator: 사용자가 관리자 사용자인지 아닌지를 나타내기 위하여 사용되는 블리언 플래그를 나타낸다.
계정
계정 레코드(2616)는 계정에 대한 정보를 포함한다. 각 계정(2616)은 그 계정하에서 동작하는 작업에 위치하는 특성과 구속을 정의한다.
account_PK: 자동적으로 생성된, 유일한 주요키이다.
name: 계정이름을 나타낸다. 이는 계정의 목적에 대한 리마인더(reminder)로서 고객에게 유용한, '의미있는'이름이다.
customer_FK: 상기 계정을 소유하는 고객을 위한 CUSTOMER 레코드에 연결된 링크를 나타낸다.
enabled: 계정이 활성화되었는지 비활성되었는지를 나타내는 블리언 플래그를 나타낸다. 비활성된 사용자는 메시지 분배 시스템에 접근할 수 없다.
enabled_change_time: 'enabled' 플래그가 지속적으로 변화되는 경우에 날짜/시간을 나타낸다. 미리 결정된 기간 동안 비활성 상태에 있는 계정은 데이터베이스에서 삭제된다.
enterprise: 상기 계정이 작업 제출을 위한 표준 인터페이스를 요구하지지 엔터프라이즈 인터페이스인지를 요구하는 지를 나타낸다.
product: 상기 계정하에서 이용될 수 있는 메시지 분배 시스템의 특징을 나타내는 코드를 나타낸다.
fax_carrier, fax_carrier_user, fax_carrier_password,
email_carrier, email_carrier_user, email_carrier_password,
sms_carrier, sms_carrier_user, sms_carrier_password,
paper_carrier, paper_carrier_user, paper_carrier_password:
'xxx_carrier'필드는 매체 'xxx'에 대하여 사용되는 캐리어를 위한 3-문자 식별자를 포함한다:
Xpedite를 위한 XPD, EDI 포스트를 위한 EDI, MessageReach를 위한 MSR, SMSReach를 위한 SMR
'xxx_carrier_user'필드 와 'xxx_carrier_password'필드는 FTP에 의하여 캐리어로 파일을 전송할 때 메시지 분배 시스템에 의하여 내부적으로 이용된다. 다른 캐리어들을 포함하는 다른 식별자들이 사용될 수 있다Ek.
fax_quality: 팩스를 위한 출력 품질 (표준 또는 고급)
fax_max_page_size: 바이트 단위로 팩스 페이지의 최대 크기를 나타낸다.
fax_cover_page: 작업을 위하여 상기 계정하에서 제출되는 팩스의 표지를 생성하는지 그렇지 않은지를 나타내는 블리언 값을 나타낸다.
fax_company, fax_address_1, fax_address_2, fax_address_3: 이들 필드들에 있는 회사 이름과 주소는 각 팩스의 표지에 인쇄된다.
email_from_address: 수신자에게 도달하는 메시지 분배 시스템-생성 전자우편들이 어디로부터 발송되었는지가 나타나는 전자우편 주소를 나타냄
email-timeout: 전자우편이 진행중에 있을 수 있는 최대 시간(작업 시도의 시점부터 시간단위 나타내는 것이 바람직함)을 나타낸다.
email_job_status_address: 작업 상태 보고가 전송된 전자우편 주소를 나타낸다.
USER_ACCOUNT_XREF
'cross-reference'엔터티(2614)는 사용자들(2612)과 계정(2616)의 단일 유효 조합을 지정한다. 각 사용자에 대하여, 상기 엔터 티는 계정을 정의하고, 사용자는 사용자가 메시지 분배 시스템에 작업을 전송한 때를 언급한다. 각 계정에 대하여, 이 엔터티(2614)는 엔터티를 사용하는 사용자들을 정의한다.
user_account_xref_PK: 자동적으로 생성된, 유일한 주요키를 나타낸다.
user_FK: USER 레코드에 연결된 링크를 나타낸다.
account_FK: ACCOUNT 레코드에 연결된 링크를 나타낸다.
작업큐
작업큐는 메시지분배 시스템의 관련 데이터베이스(2600) 내에 있는 표들의 셋으로서 존재한다. 도 25는 엔터티들의 관계를 나타낸 구성도로서, 작업큐 엔터티들은 다음과 같다:
2618, 2632, 2634, 2640; 2620, 2622, 2624, 2626, 2628, 2630; 및 2636,2638, 3642, 2644, 2646, 2648, 2650 및 2652.
일단 작업큐 엔트리가 생성되기만 하면 레코드들 (2636,2638, 3642, 2644, 2646, 2648, 2650, 2652, 2620, 2622, 2624, 26262, 2628 및 2630)은 변화하지 않는다. 반면에 레코드들 (2618, 2632, 2634 및 2640)은 작업 처리의 상태를 나타내기 위하여 때때로 갱신된다.
레코드들(2636,2638, 3642, 2644, 2646, 2648, 2650 및 2652)은 작업 제출 시간에 설정된다. 레코드들 (2620, 2622, 2624, 26262, 2628 및 2630)도 표준 인터페이스를 위한 작업 제출 시점에 설정되지만, 엔터프라이즈 인터페이스의 경우에, 작업이 여러 작업들을 걸쳐 구현되고 유지되는 때 메시지 분배 시스템 지원팀에 의하여 설정될 수 있다.
작업
작업 큐의 상부에서, 계층은 JOB 레코드(2618)가 된다. 작업 큐에는 각 JOB 레코드(2618)가 있고, JOB 레코드(2618)는 하나의 작업과 관련된 모든 정보에 대하여 '앵커(anchor)'레코드를 구성한다.
job_PK: 작업 ID는 메시지 분배 시스템에 의해서 생성된 숫자 식별자로서, 작업을 유일하게 식별한다. 그 식별자는 작업(예를 들어, 작업 상태 보고)과 관련된 출력에 나타나고 사용자가 작업을 제출하는 경우에 '확인화면'에 표시된다.
user-reference: 작업을 위한 사용자-생성 이름은 나타내고, 이는 여러 메시지 분배 시스템/과금 보고에 포함되고 사용자가 희망하는 텍스트를 포함한다.
job_configuration_FK: 상기 작업을 위하여 JOB_CONFIGURATION 레코드에 연결된 링크를 나타낸다.
account_FK: 상기 작업이 동작하는 하에서 계정을 위한 ACCOUNT 레코드에 연결된 링크를 나타낸다.
user_FK: 상기 작업을 기동하는 사용자를 위한 USER 레코드에 연결된 링크를 나타낸다.
submit_time: 작업이 제출된 날짜와 시간을 나타낸다.
fax_only: '정의된 팩스 주소를 갖는 모든 수신자들에게 팩스를 전송한다'는 의미
sms_only: '정의된 SMS 주소를 갖는 모든 수신자들에게 SMS 메시지를 전송한다'는 의미
email_only: '정의된 전자우편 주소를 갖는 모든 수신자들에게 전자우면을 전송한다'는 의미
fax_preferred: '팩스로 모든 수신자에게 전송한다 (만약에 팩스 주소가 정의된다며); 그렇지 않으면 전자우편으로 전송한다'는 의미
email_preferred: '전자우편으로 모든 수신자에게 전송한다 (만약에 전자우편주소가 정의된다며); 그렇지 않으면 팩스로 전송한다'는 의미
job_submission_folder: 폴더의 이름을 나타내고, 여러 작업 아티팩트(artifacts)(템플릿, 수신자 파일, 전송 번들 파일, 등)가 저장된다.
master_status: 전체 작업 상태
master_change_time: 날짜 및 시간을 나타내고, 마스터 상태는 지속적으로 변화된다.
작업 구성 정보
레코드 클러스터는 JOB_CONFIGURATION (2620), TEMPLATE (2624), TEMPLATE_ARTIFACT (2622), CONFIG_DATA (26226), JAVA_MAPPING_CLASS_RESOURCE (2628) 및 JAVA_MAPPING_CLASS(2630)과 같은 레코드 형태를 포함하고, 이 클러스터는 하나의 작업에 의하여 사용되는 다양한 아티팩트와 구성을 정의한다.
엔터프라이즈 인터페이스를 사용하여 제출된 작업에 대해서, 작업이 메시지 분배 시스템 지원 팀에 의하여 먼저 설정될 때, 레코드 클러스터는 정의된다. 레코드 클러스터는 많은 작업에 의하여 사용되고, 작업과 작업 사이에 변하지 않는 상태로 남아 있게 된다. 클러스터는 여러 데이터 파일 (템플릿, 이미지, 등)의 내용을 포함하고, 각 데이터 파일은 '클러스터가 설정될 때 메시지 분배 시스템 지원팀에 의하여 이진 객체(blob)로서 데이터베이스 레코드에 '불러오기(imported)'가 수행된다.
표준 인터페이스를 이용하여 제출된 작업에 대하여, 레코드의 클러스터는 작업이 제출된 시점에 생성되고 그 특정한 작업과 관련된다. 템플릿은 클러스터 내로부터 참조되지만 실질적으로 데이터베이스 자체에 저장되지 않는다. 오히려 템플릿은 단층 파일(flat file)로서 분리되어 유지된다.
JOB_CONFIGURATION
레코드(2620)는 작업 구성 레코드 클러스터를 위한 '앵커(anchor)'가 된다.
job_configuration_PK: 자동적으로 생성된, 유일한 주요키이다.
display_name: 작업구성에 대한이름을 나타내고, 이는 고객에게 의미가 있고 작업 구성을 선택하기 위하여 작업 제출 화면 ('작업 형태')에서 이용된다. 상기 필드는 엔터프라이즈 인터페이스 작업을 위해서만 정의된다.
enterprise: 작업 구성이 엔터프라이즈 인터페이스 또는 표준 인터페이스에 인가되는지를 나타내는 블리언 플래그를 나타낸다.
customer_FK: 작업 구성을 이용하여 모든 작업을 소유하는 CUSTOMER 레코드에 연결되는 링크를 나타낸다.
템플릿
레코드(2624)는 템플릿을 정의한다(즉, 병합할 수 있는 MS 워드, XSL 또는 텍스트 자료, 또는 PDF, TIFF, MTML 또는 포스트크립트 포맷으로 비-병합할 수 있는 자료). 엔터프라이즈 인터페이스 작업에 대하여, 템플릿(2624) 자체는 이진 이미지(binary image)로서 그 레코드 내에 유지된다. 표준 인터페이스 작업에 대하여, 템플릿(2624)은 단층 파일(작업 제출 폴더 내에서)로서 데이터베이스 바깥에서 유지된다.
template_PK: 자동적으로 생성된, 유일한 주요키를 나타낸다.
filename: 템플릿을 구성하는 파일의 파일이름을 나타낸다.
attach_name: 전자우편 첨부물 템플릿을 위해서 정의된 이름으로서, 수신자에게 전송될 때 첨부파일에게 붙여진다(파일 형태는 배제함).
media_type: 템플릿이 적용된 매체를 가리킴
fo_rendering_engine: 서신 템플릿을 위해서만 정의되고, 포스트크립트 출력(현재 XEP 또는 FOP)을 생성하기 위하여 메시지 분배 시스템에 의하여 사용되는 FO 렌더링 엔진의 이름을 포함한다.
job_configuration_FK: JOB_CONFIGURATION 레코드에 연결되는 링크를 나타낸다.
component_type: 이 템플릿은 최종 수신자 메시지의 어느 성분을 정의하는 지를 나타낸다.
component_sequence: 성분의 시퀀스 번호를 나타내고, 이는 'component_type'이 '첨부물'이 아닌 경우에 정의된다. 이 필드는 메시지 내에 이 첨부물의 시퀀스 번호를 나타낸다. 예를 들어, 4개의-첨부물 전자우편 메시지용 전자우편 첨부물은 1, 2, 3, 및 4로 번호가 매겨진다.
template: 이 필드는 엔터프라이즈 인터페이스 템플릿에 대하여서만 유효하고, 템플릿 자체를 포함한다. (표준 인터페이스 작업에 대해서, template은 단층 파일(flat file)로 작업 제출 폴더에서 유지된다.)
TEMPLATE_ARTIFACT
이 레코드(2622)는 JOB_CONFIGURATION (2620)에서 TEMPLATE 레코드(2624)에 의하여 사용되는 이미지 파일과 다른 멀티미디어 파일을 나타낸다. 이 레코드는 엔터프라이즈 인터페이스 작업(XSL 템플릿을 사용함)을 위하여 정의된다.
template_artifact_PK: 자동적으로 생성된, 유일한 주요키를 나타낸다.
filename: 파일의 파일이름을 나타내고, 이로부터 아티팩트(artifact)가 입력된다.
filetype: 파일의 파일 형태를 나타내고, 이로부터 아티팩트(artifact)가 입력된다 (전형으로 GIF 또는 JPG).
job_configuration_FK: JOB_CONFIGURATION 레코드로 연결되는 링크를 나타낸다.
artifact: 아티팩트 자체를 포함한다.
CONFIG_DATA
이 레코드(2626)는 매체 형태를 특정하는 구성 데이터를 포함한다. 이 레코드는 서신을 위하여 이용되고, 종이 공급기 (paper feeder)가 양면으로 인쇄하여 사용할 지에 대한 정보를 포함한다. 이 레코드는 엔터프라이즈 인터페이스 작업을 위하여 정의된다.
config_data_PK: 자동적으로 생성된, 유일한 주요키이다.
filename: 파일의 파일 이름을 나타내고, 이로부터 상기 config data 가 입력된다.
filetype: 파일의 파일형태를 나타내고, 이로부터 상기 config data 가 입력된다(전형적으로 TXT).
media_type: 상기 구성 데이터가 인가되는 매체를 나타낸다.
job_configuration_FK: JOB_CONFIGURATION 레코드에 연결되는 링크를 나타낸다.
configuration: 구성 데이터 자체를 나타낸다. 도 26은 EDI 포스트로 제출된 서류 작업을 위한 전형적인 구성 (2700)의 실시예를 나타낸 도면이다.
JAVA_MAPPING_CLASS
이 레코드(2630)는 의무적인 레코드로서 자바 클래스를 포함하고, 이 자바 클래스는 수신자 파일을 XML 로 변환하는데 이용된다(가능하다면 하나 또는 그 이상의 JAVA_MAPPING_CLASS_RESOURCES 레코드를 이용함). 표준 인터페이스 작업은 CSV-포맷된 수신자 파일을 이용하고, 그래서 그와 같은 작업은 'CSVMapping.class'라고 불려지는 표준 자바 매핑 클래스를 이용한다.
java_mapping_class_PK: 자동적으로 생성된, 유일한 주요키이다.
filename: 파일의 파일이름으로서, 이로부터 자바클래스가 입력된다.
filetype: 파일의 파일형태로서, 이로부터 자바클래스가 입력된다 (전형적으로 CLASS).
job_configuration_FK: JOB_CONFIGURATION 레코드에 연결된 링크를 나타낸다.
class: 자바클래스를 포함한다.
JAVA_MAPPING_CLASS_RESOURCE
이 레코드(2628)는 선택적이고 (optional)이고, 수신자 목록 정보를 재-포맷하기 위한 자바 매핑 클래스에 의하여 사용되는 리소스 객체를 포함한다. 이 레코드 (2628)는 소정의 리소스 형태, 예를 들어, 다른 자바 클래스, XML 스타일시트, 또는 XFlat 언어 ('XML 변환'프로덕트로 입력을 위하여)에 있는 스테이트먼트를 포함한다.
java_mapping_class_resource_PK: 자동적으로 생성된, 유일한 주요키이다.
filename: 파일의 파일이름을 나타내고, 이로부터 XFlat 매핑 데이터가 입력된다.
filetype: 파일의 파일형태를 나타내고, 이로부터 XFlat 매핑 데이터가 입력된다.
job_configuration_FK: JOB_CONFIGURATION 레코드가 연결되는 링크를 나타낸다.
resource_data: 리소스 자체를 포함한다.
도27은 리소스의 하나의 형태의 예(2800)로서, 리소스는 이 레코드에 저장된다. XFlat 스테이트먼트는 CSV 파일을 XML 파일로 변환한다. CSV 파일은 레코드마다 세 개의 필드를 포함하고, 이 세 개의 필드는 'refno,' 'name,' 및 'salary'가 된다.
수신자 정보
하나의 작업을 위하여 수신자 정보를 정의하는 레코드들(2636, 2638, 2640, 2642, 2644, 2652, 2650, 2648, 2646)은 각각 RECIPIENT레코드, ATTEMPT 레코드, TRANSMISSION 레코드, MERGE_DATA 레코드, DESTINATION 레코드, PAPER_ADDRESS_PARSED 레코드, PAPER_ADDRESS_UNPARSED 레코드, PHONE_NUMBER 레코드, 및 EMAIL_ADDRESS 레코드가 있다.
RECIPIENT레코드
각각의 레코드(2636)는 하나의 수신자를 나타낸다.
recipient_PK: 자동적으로 생성된, 유일한 주요키이다.
job_FK: 작업을 위한 JOB 레코드에 연결된 링크를 나타낸다.
title: 수신자 경칭(Mr., Mrs., Dr., 등)을 나타낸다.
first_name: 수신자의 이름을 나타낸다.
last_name: 수신자의 성을 나타낸다.
user_data: 사용자 관점으로부터 상기 수신자를 식별하기 위하여 전형적으로 사용된 사용자-정의된 데이터 필드를 나타낸다.
ATTEMPT 레코드
수신자마다 세 개의 ATTEMPT 레코드(2638)까지 존재한다. 각각은 수신자 목록 레코드에서 설명되는 것과 같이 하나의'<시도(attempt)>'를 나타낸다. ATTEMPT 레코드(2638)는 레코드가 정확한 순서로 접근될 수 있도록 번호가 매겨진 시퀀스가 된다. ATTEMPT 레코드 목적은 TRANSMISSION 레코드들을 그룹짓는 것이다.
attempt_PK: 자동적으로 생성된, 유일한 주요키이다.
recipient_FK: RECIPIENT 레코드에 연결된 링크를 나타낸다.
seq_number: 상기 시도 (1, 2 또는 3)의 시퀀스 번호를 나타낸다.
TRANSMISSION 레코드
각 시도마다 세 개의 TRANSMISSION 레코드(2640)가 존재한다. 각각은 수신자 목록 레코드에 있는 '<시도(attempt)>'요소에서 설명된 전송을 나타낸다. TRANSMISSION 레코드(2640)는 레코드가 정확한 순서로 접근될 수 있도록 번호가 매겨진 시퀀스가 된다. 제1레코드(항상 시퀀스 번호가 '1'임)는 마스터 전송 (그 전송이 실패할 경우에 재전송(redirection)을 생성함)을 나타낸다.
다음에 나열하는 필드들은 작업이 작업큐에 위치될 때 설정된다.
transmission_PK: 자동적으로 생성된, 유일한 주요키이다.
destination_FK: DESTINATION 레코드에 연결된 링크를 나타낸다.
attempt_FK: ATTEMPT 레코드에 연결된 링크를 나타낸다.
account_FK: 작업을 위하여 ACCOUNT 레코드에 연결된 링크를 나타낸다.
recipient_FK: RECIPIENT 레코드에 연결된 링크를 나타낸다.
transmission_bundle_FK: TRANSMISSION_BUNDLE 레코드에 연결된 링크를 나타낸다.
job_FK: 작업을 위하여 JOB 레코드에 연결된 링크를 나타낸다.
attempt_no: 시도 번호
seq_number: 전송 시퀀스 번호 (1, 2, 또는 3)
state: '시도되지 않음'(비활성), '성공적으로 종료'(즉, OK), '성공하지 못한 채 종료'(즉, 오류 코드) 와 같은 전송상태인지를 나타낸다.
나머지 필드들은 전송이 시도되었을 때 설정되고, 전송의 성공/실패와 관련된 정보를 포함한다.
job_reference: 작업을 위하여 사용자의 참조 id를 나타낸다.
user_data: 수신자를 위하여 사용자의 참조 id를 나타낸다.
destination_address: 전송될, 전화번호, 전자우편 주소 또는 서신 주소를 나타낸다.
data_time_job_submitted: 작업이 제출된, 날짜 및 시간을 나타낸다.
date_time_message_delivered: 메시지가 수신자에게 전달된, 날짜 및 시간을 나타낸다.
carrier_name: 캐리어의 이름(Xpedite, 등)을 나타낸다.
carrie_reference_id: 캐리어의 참조 id(예를 들어, Xpedite의 작업 번호)를 나타낸다.
medium: 전송이 수행되는 매체를 나타낸다(팩스, 서신, 등)
size_of_message: 바이트로 메시지의 전체 크기를 나타낸다.
destination_country: 메시지가 전송될 국가 또는 지역을 나타낸다.
delivery_success_failure_code: 전송의 성공 또는 실패에 대한 이유를 나타내는 캐리어의 코드를 나타낸다.
MERGE_DATA 레코드
수신자 레코드로부터 병합 데이터(2642)는 XML 텍스트 폼으로 저장된다.
merge_data_PK: 자동적으로 생성된, 유일한 주요키이다.
recipient_FK: RECIPIENT 레코드에 연결된 링크를 나타낸다.
merge_data: XML-포맷된 텍스트의 문자열로서 병합데이터 자체를 포함한다.
DESTINATION 레코드
각 수신자에 대하여, 각 매체(즉, 최대 4개)를 위하여 DESTINATION 레코드 (2644)가 있다. 레코드는 '매체 id'(팩스, 서신, SMS 또는 전자우편을 나타냄)와 단일 '서브-레코드(sub-record)'를 가리키고, 그 단일 서브-레코드는 다음에 나열하는 레코드 형태 중에 하나가 된다.
destination_PK: 자동적으로 생성된, 유일한 주요키이다.
recipient_FK: RECIPIENT 레코드에 연결된 링크를 나타낸다.
media-type: 매체를 나타내고, 이 지정은 찾기 위한 지정 주소의 형태(아래 참조)를 표시하고 지시한다.
PAPER_ADDRESS_PARSED 레코드
이 레코드(2652)는 분석되지 않은 서신 지정 주소를 포함한다.
paper_address_PK: 자동적으로 생성된, 유일한 주요키이다.
destination_FK: DESTINATION 레코드에 연결된 링크를 나타낸다.
street_address: 거리 번지 및 이름
suburg: 주택지 이름
state: 주이름
postcode: 우편번호
country: 국가이름
PAPER_ADDRESS_UNPARSED 레코드
이 레코드는 (2650)은 분석된 서신 지정 주소를 포함한다.
paper_address_unparse_PK: 자동적으로 생성된, 유일한 주요키이다.
destination_FK: DESTINATION 레코드에 연결된 링크를 나타냄
address_line_1: 주소의 라인 1
address_line_2: 주소의 라인 2
address_line_3: 주소의 라인 3
address_line_4: 주소의 라인 4
address_line_5: 주소의 라인 5
address_line_6: 주소의 라인 6
PHONE_NUMBER 레코드
이 레코드(2648)는 전화번호(즉, SMS 또는 팩스에 대한 지정 주소)를 포함한다.
phone_number_PK: 자동적으로 생성된, 유일한 주요키이다.
destination_FK: DESTINATION 레코드에 연결된 링크를 나타낸다.
country_code: 국가코드
area_code: 지역코드
local_number: 전화번호의 나머지 부분
EMAIL_ADDRESS 레코드
이 레코드(2646)는 전자우편 지정 주소를 포함한다.
email_address_PK: 자동적으로 생성된, 유일한 주요키이다.
destination_FK: DESTINATION 레코드에 연결된 링크를 나타낸다.
email_address: 전자우편 주소
is_valid: 주소 구문이 유효한지 그렇지 않은지를 나타내는 블리언 값을 나타냄
전송 번들 정보
메시지 분배 시스템이 특정한 작업 전송 시소를 처리하는 경우에, 상기 시스템은 '전송 번들'로 수신자를 정렬하고, 각각의 전송 번들은 특정한 매체에서 목표가 된다. 각 전송 번들은 캐리어로 전송되고, 전송의 최후의 단계는 캐리어 백(carrier back)으로부터 메시지 분배 시스템으로 궁극적으로 건네진다. TRANSMISSION_BUNDLE 레코드(2632)는 각 전송 번들을 위하여 생성되어 그 상태를 추적하기 위하여 이용된다.
TRANSMISSION_BUNDLE
각 전송 번들에 대하여 하나의 TRANSMISSION_BUNDLE 레코드(2632)가 있다. 상기 레코드(2632)는 번들 자체가 생성될 때 생성되고 작업이 데이터베이스로부터 최종적으로 삭제될 때 삭제된다.
transmission_bundle_PK: 자동적으로 생성된, 유일한 주요키이다.
job_FK: 상기 작업을 위하여 JOB 레코드에 연결된 링크이다.
attempt: 상기 시도의 시퀀스 번호(1, 2, 또는 3)
media_type: 상기 전송이 지정되는 매체를 나타낸다.
creation_time: 상기 레코드가 생성된 날짜와 시간을 나타낸다.
bundle_status: 상기 전송의 번들의 처리 상태. 5.3.1 절 참조
status_change_time: bundle_status가 지속적으로 변화되는 날짜와 시간을 나타낸다.
CARRIER_REFERENCE
특정한 매체 형태와 작업 id에 대하여 캐리어에게 전송된 각 전송 번들 파일을 위한 하나의 CARRIER_REFERENCE 레코드(2634)가 있다. 상기 레코드(2634)는 전송 번들 파일 자체가 생성되는 경우에 생성되고, 그 작업이 최종적으로 데이터베이스에서 삭제되는 경우에 삭제된다.
대부분의 경우에, 하나의 시도는 매체 형태마다 하나의 전송 번들 파일을 생성만하지만 경우에 따라서(예를 들어, Xpedite을 위하여 지정된 팩스 전송 파일들과 10Mbytes를 초과함 ), 그 파일은 여러 분리된 파일들로 나뉘어진다. 이와 같은 이유에 대하여, 때때로 TRANSMISSION_BUNDLE 레코드(2632)마다 여러 CARRIER_REFERENCE 레코드(2634)가 있을 수 있다.
carrie_reference_PK: 자동적으로 생성된, 유일한 주요한 키이다.
transmission_bundle_FK: TRANSMISSION_BUNDLE 레코드에 연결된 링크이다.
carrie_id: 상기 전송 번들 파일을 유일하게 나타내기 위하여 캐리어에 의하여 제공되는 식별자를 나타낸다. 상기 식별자는 캐리어로부터 피드백 정보를 poll하기 우하여 메시지 분배 시스템에 의하여 사용될 수 있다. 상기 필드의 포맷은 서로서로 변한다.
transmission_bundle_filename: 전송 번들 파일의 이름을 나타낸다.
status_collected: 캐리어 상태 보고가 상기 전송 번들 파일을 위하여 캐리어로부터 수신하는 지를 나타내기 위하 블리언 값이다. '참'이라고 설정되면, 그 정보는 수신되어 TRANSMISSION 레코드에 인가된다.
기타
NUMBER-GENERATOR
이는 싱글톤 레코드(singletone record)(2654)로서, 새로운 작업에 유일한 작업 ID들을 할당하기 위하여 사용되고 다른 레코드에 대하여 유일한 레코드 키를 할당하는 데에 사용된다.
number_generator_PK: 자동적으로 생성된, 유일한 주요키이다.
job_number: 할당된 다음 작업 id이다.
general_number: 할당된 다음 일반적인 수이다 (JOB 레코드 이외에 모든 레코드들에 대하여 레코드키로서 사용된다)
VIII. 자바 매핑 클래스와 XSL 템플릿
메시지 분배 시스템은 일반화 메시지 처리 엔진으로서 설계된다. 메시지 분배 시스템 자체의 '핵심(core)'는 소정의 지정에 대하여 소정의 형태의 메시지를 방송하도록 설계된다. 그러나 각 메시지분배 시스템 고객의 '작업 형태' (aka '작업구성')은 특별한 처리 특성을 갖는다. 이는 다음 두 개의 범주로 나뉜다.
* 고객으로부터 수신된 수신자 파일을 유효하게 하고 재-포맷하는 것
* 각 개인적으로 나뉘어진 수신자 메시지를 생성하기 위하여 템플릿에 있는 병합 필드로 병합 값을 교체하는 것
상기 각각의 처리 범주는 자바 매핑 클래스 처리와 템플릿 병합 처리라고 가리켜진다. 이들 처리 범부는 둘 다 각 고객과 작업 형태를 특정하는 처리와 연관이 있고, 각각에 대하여 프로그램/스타일시트는 그 시스템에 새로운 작업 형태를 설정하기 위한 절차의 일부로서 개발된다. 게다가, 프로그램/스타일시트의 개발은 개발팀에 의하여 수행될 수 있고, 이 개발팀은 메시지 분배 시스템 자체를 개발하는 팀으로부터 분리되어 있다.
도 28은 작업의 처리 경로(2900)가 메시지 분배 시스템 '핵심'(2910)으로부터 자바 매핑 클래스 (2930)와 템플릿 (2940)에 전해지고 다시 되돌아오는 작업 실행의 흐름을 나타낸 구성도이다.
메시지 분배 시스템 (2910)의 '핵심'은 변화하지 않는다. 시스템 소프트웨어(2910)는 일반화된 플랫폼을 나타내고, 메시지 분배 시스템의 형태는 그 플랫폼에서 동작한다. 고객-특정 성분(2930 및 2940)은 각 작업 형태에 대하여 다르다.
단계(2920)에서, 사용자는 시스템 소프트웨어(2910)로 소정의 작업을 제출한다. 작업 정보는 단계 (2912)에서 합쳐진다. 자바 매핑 클래스(2930)에서, 수신자 목록은 단계 (2932)에서 유효하게 된다. 그 다음에 수신자 목록은 단계 (2934)에서 매핑된다. 그 다음에 처리 절차는 그 작업이 단계 (2914)에서 시작되는 경우에 시스템 소프트웨어 (2910)에서 계속된다. 단계 (2916)에서, 다음 수신자의 병합 데이터는 구해진다 ('구하다'). 템플릿(2940)은 템플릿 병합 필드로 수신자의 갑을 교체한다. 메시지들은 단계 (2918)에서 수신자로 전송되고, 또한 다음 수신자 병합 데이터는 단계 (2916)에서 구해진다.
자바 매핑 클래스
자바 매핑 클래스(2930)(다른 경우에서는, 데이터 변환기로 알려짐)는 메시지 분배 시스템 (2900)의 강력한 특징이다. 그 클래스는 (2930)은 고객의 수신자 데이터가 소정의 포맷으로 메시지 분배 시스템으로 제공되는 것을 허용한다. 자바 매핑 클래스 (2930)는 메시지 분배 시스템 (2910) 자체에 대하여 분리되어 부속되어 있고, 이는 특정한 고객이 작업을 조절한다(tailored). 제VI절에서 설명한 과 같이, 그 클래스 (2930)는 모든 고객이 수신자 목록을 수신자 메시지 시스템의 표준 포맷으로 변환한다. 그 클래스(2930)는 고객의 수신자 목록으로 범용 변화를 자동적으로 수행하게 할 능역을 제공한다. 예를 들어, 자바 매핑 크래스(2930)는 NSW에 있는 모든 수신자들에게 '팩스에 의한 전송'과 같이 일반적인 요구상항을 구현하지만 전자우편을 통해서는 다른 수신자들에게 전송하는 것을 구현한다. 각 작업 형태(aka '작업 구성')에 대하여 하나의 자바 매핑 클래스 (2930)가 있고, 그 기능은 고객으로부터 수신한 수신자 파일을 유효하게 하고 이를 메시지 분배 시스템의 표준 수신자 포맷으로 변환한다.
클래스(2930)는 두 개의 주요 방법, '유효화' 및 '맵'을 제공하고, 필요하면 이 두 주요방법은 메시지 분배 시스템에 의하여 불리어진다. 자바 매핑 클래스(2930)자체는 데이터베이스(JAVA_MAPPING_CLASS 레코드 내에서)와 다양한 리소스에서 유지되고, 상기 클래스 요구(즉, XFlat 개요표 및 XSL T 스타일시트)는 데이터베이스(JAVA_MAPPING_CLASS_RESOURCE 레코드)에서 유지된다.
특별한 자바 매핑 클래스 환경
자바 매핑 클래스의 클래스 파일은, 다른 메시지 분배 시스템 클래스와 같이, JAR 파일 내에 저장되지 않는다; 대신에 상기 파일은 작업 구성의 일부로서, JAVA_MAPPING_CLASS 레코드에서 데이터베이스 내에 유지된다. 메시지 분배 시스템은 클래스 파일이 요구될 때마다 데이터베이스에서 메모리에 저장된 클래스 파일을 자동적으로 읽고, JAVA ClassLoader 의 특별한 메시지 분배 시스템 서브 클래스 (이후에는 '특별 ClassLoader'라고 부르기로 함)를 이용하여 그 파일을 로딩한다.
자바 가상 머신은 클래스들을 로딩하기 위하여 사용된 ClassLoader에 의하여 모든 클래스들을 구별한다. 특정 ClassLoader에 의하여 로딩된 클래스들은 다른 클래스들에 접근할 수만 있고, 다른 클래스들은 그 ClassLoader를 위하여 '클래스경로(classpath)'에서 구체적으로 지정된다. 자바 가상 머신은 분리된 '세계들'로 분리된다. 같은 ClassLoader와 함께 로딩되는 모든 클래스들은 직접적으로 다른 클래스에 접근할 수 있지만, 하나의 '세계'에 있는 하나의 클래스는 다른 '세계'의 클래스에 쉽게 접근할 수 없다. 여기서, '세계'라는 용어는 상기 개념을 설명하기 위하여 만들어진 신조어이다.
자바 특징은 자바 매핑 클래스들이 메시지 분배 시스템 '핵심'클래스들로 접근하는 것을 제한하기 위하여 의도적으로 사용된다. 자바 매핑 클래스들은 나머지 메시지 분배 시스템과 다른 '세계'에서 동작한다:
* 메시지 분배 시스템 클래스들의 핵심은 모든 자바 SDK 패키지(java.io, java.util, 등)와 모든 고객-개발된 메시지 분배 시스템 패키지에 접근할 수 있다.
* 자바 매핑 클래스들은 모든 표준 자바 SDK 패키지(java.io, java.util, 등)와 특별한 자바 매핑 클래스 패키지(com.system.mapper)에만 접근할 수 있다.
따라서, 자바 매핑 클래스들은 메시지 분배 시스템으로부터 '분리(divorced)'되고 그 메시지 분배 시스템에 접근할 수 없다. 따라서, 자바 매핑 클래스들은 그 메시지 분배 시스템 자체에 대한 대응하는 변화를 요구하지 않은 채 향상되거나 수정될 수 있다. 이는 시스템 관리를 상당히 단순하게 하고 '로그(rougue)' 자바 매핑 클래스에 대항하는 시스템을 보호한다.
메시지 분배 시스템 자체는 그 자바 매핑 클래스들은 같은 자바 가상 머신 내에서 분리된 '섬들(islands)'로서 가시화 될 수 있다. 메시지 분배 시스템은 '반영(reflection) API'(보통 방법 시동(invocations)은 동작하지 않음)를 이용하여 자바 매핑 클래스들에게 인자들(arguments)을 넘겨준다.
인자-넘겨주기 메카니즘(argument-passing)에 대하여, 실질적인 보기로서, 엔터프라이즈 작업을 위하여 작업 정보(작업 id, 작업참조, 작업제출 폴더 및 수신자 파일)가 메시지 분배 시스템으로부터 자바 매핑 클래스로 넘겨주는 방법을 고려해 보자.
메시지 분배 시스템은 모든 정보와 그 이상(간단한 문자열과 다른 메시지 분배 시스템-정의 클래스들을 포함하는, 다양한 포맷으로 저장됨)을 포함하는 'EnterpriseJobSubmission'이라고 불리는 클래스를 포함한다. 분명한 전략은 자바 매핑 클래스에 있는'setJobSubmission' 방법으로 EnterpriseJobSubmission 객체를 간단하게 건네주는 것이다. 이와 같은 동작은 실패한다. 왜냐하면 자바 매핑클래스가 'EnterpriseJobSubmission' 클래스에 대한 지식을 가지고 있지 않기 때문이다. 즉, 상기 클래스의 정의는 자바 매핑 클래스를 로딩하기 위하여 이용되었던 ClassLoader 로 공급되는 클래스경로에 포함되지 않기 때문이다. 즉, 자바 매핑 클래스는 그 자신의 '세계'에서 클래스들만을 알고 있고; 그 클래스는 메시지 분배 시스템의'세계'에서 클래스들에 대해서는 알지 못한다. 그러나, 각 자바 매핑 클래스 'EnterpriseJobSubmissionData'라고 불리우는 클래스에 대해서 알고 있다. 상기 클래스의 정의는 자바 매핑 클래스 자신의'세계'의 일부가 된다(따라서 메시지 분배 시스템의 세계의 일부가 아님). 따라서, 자바 매핑 클래스를 유발하기 전에, 메시지 분배 시스템은 EnterpriseJobSubmissionData(특별한 ClassLoader를 이용함)의 순간을 생성하고, 그 'setter' 방법을 이용하여 필요한 데이터(즉, 작업 id, 작업 참조, 작업 제출 폴더 및 수신자 파일들)를 그 순간에 위치시킨다. 메시지 분배 시스템은 반영에 의하여 이들 세터(setter) 방법들을 유발해야만 한다. 왜냐하면 그 객체가 다른'세계'에 존재하기 때문이다. 그 다음에 메시지 분배 시스템은 자바 매핑 클래스 자체의 순간을 생성한다(다시 특별한 ClassLoader를 이용함). 마지막으로, 그 시스템은 세터 방법을 사용하여 자바 매핑 클래스(2930)로 EnterpriseJobSubmissionData 객체를 건네준다.
자바 매핑 클래스 (2930)는 상기 객체에 접근하여 일반적인 방식으로 하나의 멤버 변수에 그 객체를 저장한다. 왜냐하면, 그 객체는 그 자신의'세계'에 있고 모든 객체는 단순한 객체(문자열, 배열, 파일, 등)로서, 이는 표주 자바 환경의 일부가 되기 때문이다. 메시지 분배 시스템과 자바 매핑 클래스(2930) 사이의 정보를 건네주는 것은 방금 설명한 기술을 이용한다.
자바 매핑 클래스 방법
엔터프라이즈 인터페이스 작업용 자바 매핑 클래스는 EnterpriseMapper 클래스(이는 차례대로 Mapper 클래스를 확장함)를 확장해야만 하고 CustomMapper 인터페이스도 구현해야만 한다. 이는 표5에 나타낸 방법들을 요구한다.
[표 5]
방법 형태 방법 서명 정의된 곳 설명
public void setJobSubmissionData(객체 jobSubmissionData); Mapper 작업에 대한 정보를 설정
public void SetMappingResoures (ArrayListmappingResources); Mapper 매핑 리소스에 대한 정보를 설정(XFlate 파일, XSL 템플릿, 등)
public boolean validate(); Java Mapping Class 수신자 파일을 유효화함
public boolean map(); Java Mapping Class 매핑된 수신자 파일 생성
public String GetErrorMessage(); Mapper 오류 메시지 텍스트 구함
public String getEventId(); Mapper 이벤트 id 구함
public boolean isUserError(); Mapper 사용자 오류가 발생하면 참
public int getErrorCode(); Mapper 오류 코드를 구함
public File getMapperRecipientFile(); EngerpriseMapper 매핑된 수신자 파일 구함
지금까지 설명한 본 발명의 명세서에는, 수신자 전달 선호와 병합 점증적 증대를 바탕으로, 다중 전달 매체를 통하여 단일 수신자 셋들로 정보를 전달하는 벌크통신 방법, 시스템 및 컴퓨터 프로그램제품에 대하여 개시되어 있다. 본 발명의 명세서에는 상대적으로 작은 수의 실시예들이 설명되었지만, 당업자라면 본 발명의 개시된 실시예들로부터, 본 발명의 사상과 범위를 벗어나지 않고 많은 변형예 및/또는 대체예가 있을 수 있으리라고 쉽게 알 수 있을 것이다.

Claims (36)

  1. 팩시밀리, 전자우편, 일반우편, 및 단문 메시지 전송을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하기 위한 벌크 통신 방법에 있어서,
    단일 인터페이스부를 통하여 수신자에 대한 정보를 포함하는, 분배를 위한 정보를 수신하는 단계; 및
    상기 수신자의 전달 선호(preferences)를 바탕으로 상기 각각의 수신자에 대하여 상기 전달 매체 중에 하나를 이용하여, 상기 수신된 정보를 바탕으로 하는, 최소한 하나의 자료를 전송하는 단계를 포함하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신 방법.
  2. 제 1 항에 있어서, 상기 지정된 전달 매체에 의하여 전송이 이루어지지 않은, 하나 또는 그 이상의 수신자들의 각각에 대하여 상기 전달매체 중에서 다른 전달매체를 이용하여 최소한 하나의 자료를 점증적으로 전송하는 단계를 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  3. 제 1 항에 있어서, 상기 수신정보는 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 데이터를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  4. 제 3 항에 있어서, 상기 수신자들의 각각에 대하여 상기 최소한 하나의 자료를 제공하기 위하여, 상기 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 상기 데이터를 병합하는 단계를 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  5. 제 4 항에 있어서, 각 전달 매체에 대한 자료 템플릿을 결정하여 상기 자료 템플릿 형태를 위한 병합처리를 선택하는 단계를 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  6. 제 5 항에 있어서, 각 수신자를 지정하는 상기 데이터는 상기 각 병합 처리에 제공하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  7. 제 2 항에 있어서, 상기 최소한 하나의 자료를 각 수신자를 위하여 특정한 하나 또는 다른 전달 매체에 적합한 형식으로 변환하는 단계; 및
    상기 지정된 하나의 전달매체 또는 상기 다른 전달 매체를 이용하여 전송 캐리어에게 상기 형식화된 자료를 전송하는 단계를 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  8. 제 7 항에 있어서, 상기 각 수신자에게 상기 자료의 전달에 관한 상태 정보를 제공하기 위하여 상기 전송에 관한 상기 캐리어로부터 보고를 처리하는 단계를 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  9. 제 8 항에 있어서, 상기 점증적 증가 단계는 상기 상태 정보에 종속적인 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  10. 제 1 항에 있어서, 상기 전달 매체는 저장소를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  11. 제 1 항에 있어서, 상기 전달매체는 하나 또는 그 이상의 새로운 매체 형태를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 방법.
  12. 팩시밀리, 전자우편, 일반우편 및 단문 메시지 전송을 포함하는 다중 전달매체를 통하여 수신자에게 정보를 전달하기 위한 벌크 통신 시스템에 있어서,
    수신자들에 관한 정보를 포함하는, 분배를 위한 정보를 수신하는 단일 인터페이스부; 및
    상기 수신자의 전달 선호(preferences)를 바탕으로 상기 각각의 수신자에 대하여 상기 전달 매체 중에 하나를 이용하여, 상기 수신된 정보를 바탕으로 하는, 최소한 하나의 자료를 전송하는 수단을 포함하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신 시스템.
  13. 상기 지정된 전달 매체에 의하여 전송이 이루어지지 않은, 하나 또는 그 이상의 수 각각에 대하여 상기 전달매체 중에서 다른 전달매체를 이용하여 최소한 하나의 자료를 점증적으로 전송하는 수단을 더 포함하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신 시스템.
  14. 상기 수신정보는 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 데이터를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  15. 제 4 항에 있어서, 상기 수신자들의 각각에 대하여 상기 최소한 하나의 자료를 제공하기 위하여, 상기 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 상기 데이터를 병합하는 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  16. 각 전달 매체에 대한 자료 템플릿을 결정하는 수단과 상기 자료 템플릿 형태를 위한 병합처리를 선택하는 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  17. 제 16 항에 있어서, 각 수신자를 지정하는 상기 데이터는 상기 각 병합 처리에 제공하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  18. 제 13 항에 있어서, 상기 최소한 하나의 자료를 각 수신자를 위하여 특정한 하나 또는 다른 전달 매체에 적합한 형식으로 변환하는 수단; 및
    상기 지정된 하나의 전달매체 또는 상기 다른 전달 매체를 이용하여 전송 캐리어에게 상기 형식화된 자료를 전송하는 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  19. 제 18 항에 있어서, 상기 각 수신자에게 상기 자료의 전달에 관한 상태 정보를 제공하기 위하여 상기 전송에 관한 상기 캐리어로부터 보고를 처리하는 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  20. 제 19 항에 있어서, 상기 점증적 증가 수단은 상기 상태 정보에 종속적인 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  21. 제 12 항에 있어서, 상기 전달 매체는 저장소(archiving)를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  22. 제 12 항에 있어서, 상기 전달매체는 하나 또는 그 이상의 새로운 매체 형태를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신 시스템.
  23. 팩시밀리, 전자우편, 일반우편, 및 단문 메시지 전송을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하는 벌크 통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 매체를 포함하는 컴퓨터 프로그램 제품에 있어서,
    단일 인터페이스부를 통하여 수신자에 대한 정보를 포함하는, 분배를 위한 정보를 수신하는 컴퓨터 프로그램 코드 수단; 및
    상기 수신자의 전달 선호(preferences)를 바탕으로 상기 각각의 수신자에 대하여 상기 전달 매체 중에 하나를 이용하여, 상기 수신된 정보를 바탕으로 하는, 최소한 하나의 자료를 전송하는 컴퓨터 프로그램 수단을 포함하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  24. 제 23 항에 있어서, 상기 지정된 전달 매체에 의하여 전송이 이루어지지 않은, 하나 또는 그 이상의 수신자들의 각각에 대하여 상기 전달매체 중에서 다른 전달매체를 이용하여 최소한 하나의 자료를 점증적으로 전송하는 컴퓨터 프로그램 코드 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  25. 제 23 항에 있어서, 상기 수신정보는 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 데이터를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  26. 제 25 항에 있어서, 상기 수신자들의 각각에 대하여 상기 최소한 하나의 자료를 제공하기 위하여, 상기 하나 또는 그 이상의 템플릿과 각 수신자를 지정하는 상기 데이터를 병합하는 컴퓨터 프로그램 코드 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  27. 제 26 항에 있어서, 각 전달 매체에 대한 자료 템플릿을 결정하여 상기 자료 템플릿 형태를 위한 병합처리를 선택하는 컴퓨터 프로그램 코드 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  28. 제 27 항에 있어서, 각 수신자를 지정하는 상기 데이터는 상기 각 병합 처리에 종속적인 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  29. 제 24 항에 있어서, 상기 최소한 하나의 자료를 각 수신자를 위하여 특정한 하나 또는 다른 전달 매체에 적합한 형식으로 변환하는 컴퓨터 프로그램 코드 수단; 및
    상기 지정된 하나의 전달매체 또는 상기 다른 전달 매체를 이용하여 전송 캐리어에게 상기 형식화된 자료를 전송하는 컴퓨터 프로그램 코드 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  30. 제 29 항에 있어서, 상기 각 수신자에게 상기 자료의 전달에 관한 상태 정보를 제공하기 위하여 상기 전송에 관한 상기 캐리어로부터 보고를 처리하는 컴퓨터 프로그램 코드 수단을 더 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  31. 제 30 항에 있어서, 상기 점증적 증가를 위한 컴퓨터 프로그램 코드 수단은 상기 상태 정보에 종속적인 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  32. 제 23 항에 있어서, 상기 전달 매체는 저장소(archiving)를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  33. 제 23 항에 있어서, 상기 전달매체는 하나 또는 그 이상의 새로운 매체 형태를 포함하는 것을 특징으로 하는 다중 전송 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
  34. 팩시밀리, 전자우편, 일반우편, 및 단문 메시지 전송을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하기 위한 벌크 통신 방법에 있어서, 본 출원에 첨부된 도1 내지 도10에서 어느 하나를 참조하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신 방법.
  35. 팩시밀리, 전자우편, 일반우편 및 단문 메시지 전송을 포함하는 다중 전달매체를 통하여 수신자에게 정보를 전달하기 위한 벌크 통신 시스템에 있어서, 본 출원에 첨부된 도1 내지 도10에서 어느 하나를 참조하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신 시스템.
  36. 팩시밀리, 전자우편, 일반우편, 및 단문 메시지 전송을 포함하는 다중 전달 매체를 통하여 수신자에게 정보를 전달하는 벌크 통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 매체를 포함하는 컴퓨터 프로그램 제품에 있어서, 본 출원에 첨부된 도1 내지 도10에서 어느 하나를 참조하는 것을 특징으로 하는 다중 전달 매체를 이용한 벌크통신용 컴퓨터 프로그램이 저장된 컴퓨터 프로그램 제품.
KR1020057001585A 2002-07-29 2003-07-29 다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템 KR20050027134A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2002950435 2002-07-29
AU2002950435A AU2002950435A0 (en) 2002-07-29 2002-07-29 A Bulk Communications Process Using Multiple Delivery Media

Publications (1)

Publication Number Publication Date
KR20050027134A true KR20050027134A (ko) 2005-03-17

Family

ID=27809532

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057001585A KR20050027134A (ko) 2002-07-29 2003-07-29 다중 전달 매체를 이용한 벌크통신 방법 및 그 시스템

Country Status (9)

Country Link
US (1) US7715032B2 (ko)
EP (1) EP1546970A4 (ko)
JP (1) JP2005535013A (ko)
KR (1) KR20050027134A (ko)
CN (1) CN1672158A (ko)
AU (1) AU2002950435A0 (ko)
CA (1) CA2493311A1 (ko)
NZ (1) NZ537862A (ko)
WO (1) WO2004012109A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200032379A (ko) * 2018-09-18 2020-03-26 주식회사 에벤에셀케이 연결문서 생성 및 열람 방법, 장치, 및 이에 대한 컴퓨터프로그램

Families Citing this family (82)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2443454A1 (en) 2003-09-11 2005-03-11 Teamplate Inc. Data binding method in workflow system
CA2451164C (en) * 2003-09-11 2016-08-30 Teamplate Inc. Customizable components
KR100663568B1 (ko) * 2003-12-26 2007-01-02 삼성전자주식회사 이동단말기의 문자메시지 머리글 혹은 바닥글 작성 장치및 방법
US8112103B2 (en) * 2004-01-16 2012-02-07 Kuang-Chao Eric Yeh Methods and systems for mobile device messaging
US7151932B2 (en) 2004-02-27 2006-12-19 Research In Motion Limited Methods and apparatus for facilitating the delivery of e-mail using a packet data service or a short messaging service (SMS)
DE602004010878T2 (de) * 2004-02-27 2009-01-02 Research In Motion Ltd., Waterloo Verfahren und Gerät zum Erleichtern der Abgabe von elektronischer Post durch einen Paketdienst oder einen Kurznachrichtendienst (SMS)
US20050243978A1 (en) * 2004-04-14 2005-11-03 Lg Electronics Inc. System and method of interworking messages between mobile communication terminals
US7765264B2 (en) * 2004-07-12 2010-07-27 At&T Mobility Ii Llc Selection of bearer mode according to message characteristics
JP4262651B2 (ja) * 2004-08-12 2009-05-13 株式会社リコー 画像形成装置
US8296354B2 (en) 2004-12-03 2012-10-23 Microsoft Corporation Flexibly transferring typed application data
US8527870B2 (en) * 2004-12-23 2013-09-03 Oracle International Corporation Flexible electronic document that receives data insertion from one or more data sources
US8429527B1 (en) * 2005-07-12 2013-04-23 Open Text S.A. Complex data merging, such as in a workflow application
US8745140B2 (en) * 2005-10-14 2014-06-03 Blackberry Limited System and method of handling messages for forwarding
US7925710B2 (en) * 2006-01-31 2011-04-12 Microsoft Corporation Simultaneous API exposure for messages
US8494281B2 (en) * 2006-04-27 2013-07-23 Xerox Corporation Automated method and system for retrieving documents based on highlighted text from a scanned source
WO2007134265A2 (en) * 2006-05-12 2007-11-22 Captaris, Inc. Workflow data binding
JP5201808B2 (ja) * 2006-06-15 2013-06-05 キヤノン株式会社 電子文書処理装置及び電子文書処理方法
US20080071725A1 (en) 2006-09-01 2008-03-20 Yahoo! Inc. User-converted media marketplace
US20080104501A1 (en) * 2006-10-27 2008-05-01 Sap Ag Cross-tier intelligent document generation and management
CN101196886B (zh) * 2006-12-08 2011-01-05 鸿富锦精密工业（深圳）有限公司 Word文件转换成XML文件的***及方法
US20080222074A1 (en) * 2007-02-22 2008-09-11 Peter Lieberwirth Method or corresponding system employing templates for creating an organizational structure of knowledge
US8289538B2 (en) * 2007-03-28 2012-10-16 Moore Wallace North America, Inc. Systems and methods for managing print jobs
US20080270911A1 (en) * 2007-04-24 2008-10-30 Nehal Dantwala System and method to develop a custom application for a multi-function peripheral (mfp)
US8954476B2 (en) 2007-08-06 2015-02-10 Nipendo Ltd. System and method for mediating transactions of digital documents
US8208947B2 (en) * 2007-08-31 2012-06-26 At&T Intellectual Property I, Lp Apparatus and method for multimedia communication
US8327264B2 (en) * 2007-09-27 2012-12-04 Sap Ag Document personalizer
US7881243B2 (en) 2007-10-02 2011-02-01 Research In Motion Limited Method and apparatus capable of unified multi-transport message handling
EP2045985B1 (en) 2007-10-02 2011-04-20 Research In Motion Limited Method and apparatus capable of unified multi-transport message handling
US8184304B2 (en) 2007-11-19 2012-05-22 Moore Wallace North America, Inc. System and method of operating a raster image processor
US8564808B2 (en) * 2007-12-18 2013-10-22 R. R. Donnelley & Sons Company Systems and methods for processing of variable documents
US8301705B2 (en) * 2008-02-29 2012-10-30 Sap Ag Subject line personalization
US8472987B2 (en) * 2008-07-01 2013-06-25 Aneesh Bhatnagar Short message service (SMS) message integration with customer relationship management (CRM) applications
SG157991A1 (en) * 2008-07-04 2010-01-29 3Rd Brand Pte Ltd Company Regi Extended messaging platform
US20100110467A1 (en) * 2008-11-06 2010-05-06 Coniglio Paul A System and Method of Rasterizing PDF Files using Multiple Processors
US8229946B1 (en) * 2009-01-26 2012-07-24 Sprint Communications Company L.P. Business rules application parallel processing system
JP5293251B2 (ja) * 2009-02-17 2013-09-18 株式会社リコー 情報処理装置、生成システム、画像形成装置、生成方法およびプログラム
JP5355227B2 (ja) * 2009-05-29 2013-11-27 株式会社東芝 文書管理支援システム、情報管理サーバ装置及び情報媒体制御装置
JP5704800B2 (ja) * 2009-07-10 2015-04-22 キヤノン株式会社 データ処理装置、データ処理処理方法、プログラム
US20110087746A1 (en) * 2009-10-12 2011-04-14 Sagi Surya R System and Method for Electronic Delivery of Mail
US9208141B2 (en) 2010-02-05 2015-12-08 Oracle International Corporation Generating and displaying active reports
US8572496B2 (en) * 2010-04-27 2013-10-29 Go Daddy Operating Company, LLC Embedding variable fields in individual email messages sent via a web-based graphical user interface
US8645248B2 (en) * 2010-10-27 2014-02-04 Hsbc Technology & Services (Usa) Inc. Integrated customer communications computer system and process for implementing same
US8676236B1 (en) 2010-07-12 2014-03-18 Amdocs Software Systems Limited System, method, and computer program for generating a short message service (SMS) message using template codes
ES2676394T3 (es) * 2012-01-16 2018-07-19 Carlos TICÓ FARRÉ Un procedimiento, un sistema y un producto de programa informático para certificar que un servidor de correo electrónico de destino ha recibido un mensaje de correo electrónico enviado por un emisor a al menos una dirección de destino
LT2632096T (lt) * 2012-02-21 2017-06-12 Lleidanetworks Serveis Telematics S.A. Elektroninių pranešimų pristatymo sertifikavimo būdas
EP2632097A1 (en) * 2012-02-21 2013-08-28 Lleidanetworks Serveis Telemàtics S.A. Method for certifying delivery of SMS/MMS data messages to mobile terminals
US8775448B2 (en) * 2012-04-24 2014-07-08 Responsys, Inc. High-throughput message generation
US9990378B2 (en) * 2012-06-27 2018-06-05 Microsoft Technology Licensing, Llc Opportunistic clearing of sync states associated with a database
US9338108B2 (en) 2012-07-23 2016-05-10 Xpedite Systems, Llc Inter-modal messaging communications
US20140100861A1 (en) * 2012-10-09 2014-04-10 David Gerard Ledet Medical analysis application and response system
US8566414B2 (en) * 2012-10-12 2013-10-22 Freedomone Mobile, Inc. Systems and methods for subscription management in a multi-channel context aware communication environment
PT2723023T (pt) * 2012-10-19 2020-04-30 Lleidanetworks Serveis Telematics Sa Método para o registo e a certificação da receção de correio eletrónico
WO2014078930A1 (en) * 2012-11-21 2014-05-30 Blackberry Limited Contact prioritized communication for voice commands
US9304862B2 (en) * 2013-07-10 2016-04-05 Smartfocus Holdings Limited Method of handling an email messaging campaign
US9282066B2 (en) * 2013-07-18 2016-03-08 International Business Machines Corporation Targeted message response
US20150339285A1 (en) * 2014-04-22 2015-11-26 Aman Safaei Methods and Systems for Batch Generation and Delivery of Customized Documents
US9166936B1 (en) 2014-06-26 2015-10-20 Parlant Technology, Inc. Message customization
US9565147B2 (en) 2014-06-30 2017-02-07 Go Daddy Operating Company, LLC System and methods for multiple email services having a common domain
US11057325B2 (en) 2014-09-24 2021-07-06 Zoho Corporation Private Limited Methods and apparatus for enhanced communication in email applications
US11323401B2 (en) * 2014-09-24 2022-05-03 Zoho Corporation Private Limited Email interface for application creation and management
US11838254B2 (en) 2014-09-24 2023-12-05 Zoho Corporation Private Limited System and method for transforming communication stream messages to email messages
US11768994B1 (en) * 2014-12-16 2023-09-26 EMC IP Holding Company LLC Methods, systems, and computer readable mediums for generating a curated user interface (UI) marker
US9661521B2 (en) * 2015-01-08 2017-05-23 Freescale Semiconductor, Inc. Interrupt handling system for cellular communication network
US10263946B2 (en) * 2015-05-08 2019-04-16 Humana Inc. Enterprise message management system and method
US20160335673A1 (en) * 2015-05-12 2016-11-17 Xero Limited Smart lists
US10313291B2 (en) 2015-05-21 2019-06-04 Quest Software Inc. Method for determining predictive response time across enterprise communication systems
US10248314B2 (en) * 2015-06-04 2019-04-02 Quest Software Inc. Migrate nickname cache for email systems and devices
US10402381B2 (en) 2015-06-04 2019-09-03 Quest Software Inc. Determine confidence of mail archive ownership from senders in “sent items” folder
EP3188435B1 (en) * 2015-12-28 2019-11-13 Lleidanetworks Serveis Telemàtics S.A. Method for certifying an electronic mail comprising a trusted digital signature by a telecommunications operator
US10951569B2 (en) * 2016-02-17 2021-03-16 Salesforce.Com, Inc. Generating interactive emails and tracking user interactions
US10298634B2 (en) 2016-08-28 2019-05-21 Microsoft Technology Licensing, Llc Join feature restoration to online meeting
US20180063045A1 (en) * 2016-08-28 2018-03-01 Microsoft Technology Licensing, Llc Mitigation of online meeting invitation failure
BE1023607B1 (fr) * 2016-12-22 2017-05-15 Valipat Sa Methode et systeme de collecte de documents numeriques a partir d’une pluralite de source
CN107357773B (zh) * 2017-07-12 2021-01-29 国信电子票据平台信息服务有限公司 一种pdf电子***的生成方法及***
CN108551418B (zh) * 2018-02-28 2021-02-23 深圳市彬讯科技有限公司 一种消息平台管理方法、装置、设备及存储介质
JP2020119382A (ja) * 2019-01-25 2020-08-06 ａＤｓＦａｃｔｏｒｙ株式会社 配信装置及び配信方法
CN112307224A (zh) * 2020-11-20 2021-02-02 广州欢网科技有限责任公司 互联网电视媒资生成与管理方法、装置和***
CN115129665A (zh) * 2021-03-25 2022-09-30 易保网络技术(上海)有限公司 一种文件处理方法、***以及计算机设备和介质
US11922114B2 (en) 2021-05-24 2024-03-05 Docusign, Inc. Bulk envelope management in document management system
US11405511B1 (en) 2021-08-18 2022-08-02 Biscom Inc. System and method to deliver messages and documents using a global registry
US11537782B1 (en) 2022-04-29 2022-12-27 Docusign, Inc. Bulk envelope management in a document management system
KR102633670B1 (ko) * 2023-01-17 2024-02-05 주식회사 포스토피아 전자 등기 통합 발송 시스템 및 방법

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06125358A (ja) 1992-10-13 1994-05-06 Toshiba Corp 電子メールシステム
JPH09233216A (ja) 1996-02-23 1997-09-05 Ricoh Co Ltd マルチメディア一括通信制御システム
US5892909A (en) 1996-09-27 1999-04-06 Diffusion, Inc. Intranet-based system with methods for co-active delivery of information to multiple users
AU5670998A (en) 1997-01-15 1998-08-07 British Telecommunications Public Limited Company Method and apparatus for messaging
JP3714441B2 (ja) 1997-04-28 2005-11-09 松下電器産業株式会社 サーバシステムとそのプロトコル処理方法
DE19801563B4 (de) 1998-01-19 2006-04-20 Telefonaktiebolaget Lm Ericsson (Publ) Kommunikationssystem mit Unterstützung mobiler Teilnehmer und automatischer Informations- und Medienumsetzung
JP4745478B2 (ja) 1999-01-29 2011-08-10 キヤノン株式会社 ネットワークプリントシステム及び情報処理装置及びその制御方法
EP1126394A1 (en) 2000-02-03 2001-08-22 RDA Interactive LLC System and method for generation of interactive direct marketing using the internet
JP2001237873A (ja) 2000-02-22 2001-08-31 Canon Inc 電子メールシステムおよび電子メール通信方法
DE60020518T2 (de) * 2000-03-01 2006-06-29 Sony International (Europe) Gmbh Verwaltung von Benutzerprofilen
US6438584B1 (en) * 2000-03-07 2002-08-20 Letter Services, Inc. Automatic generation of graphically-composed correspondence via a text email-interface
JP2001331745A (ja) 2000-05-19 2001-11-30 Nec Yonezawa Ltd データサービス方法、データ処理システム、上位処理装置、情報記憶媒体
JP4406910B2 (ja) 2000-07-12 2010-02-03 日本曹達株式会社 密閉容器中の液状有害物質抜取装置及び方法
JP2002057837A (ja) 2000-08-08 2002-02-22 Canon Inc 通信装置、通信方法および記憶媒体
US7272662B2 (en) * 2000-11-30 2007-09-18 Nms Communications Corporation Systems and methods for routing messages to communications devices over a communications network
US20020184086A1 (en) * 2001-04-19 2002-12-05 Leif Linde Method and system for distributing targeted advertising
US7313617B2 (en) * 2001-09-28 2007-12-25 Dale Malik Methods and systems for a communications and information resource manager
US7076533B1 (en) * 2001-11-06 2006-07-11 Ihance, Inc. Method and system for monitoring e-mail and website behavior of an e-mail recipient
JP2003288311A (ja) 2002-03-28 2003-10-10 Toppan Printing Co Ltd 電子文書交付システム、及び電子交付方法

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200032379A (ko) * 2018-09-18 2020-03-26 주식회사 에벤에셀케이 연결문서 생성 및 열람 방법, 장치, 및 이에 대한 컴퓨터프로그램

Also Published As

Publication number Publication date
WO2004012109A1 (en) 2004-02-05
EP1546970A4 (en) 2008-01-23
AU2002950435A0 (en) 2002-09-12
US7715032B2 (en) 2010-05-11
CN1672158A (zh) 2005-09-21
CA2493311A1 (en) 2004-02-05
US20080278740A1 (en) 2008-11-13
NZ537862A (en) 2006-11-30
EP1546970A1 (en) 2005-06-29
WO2004012109A9 (en) 2004-03-25
JP2005535013A (ja) 2005-11-17

Similar Documents

Publication Publication Date Title
US7715032B2 (en) Bulk communications process using multiple delivery media
US8645248B2 (en) Integrated customer communications computer system and process for implementing same
US7392289B2 (en) Method, system, and program product for automatically formatting electronic mail addressed to an intended recipient
US6615234B1 (en) System and method for network-based document delivery
TW466858B (en) Method and apparatus for delivering documents over an electronic network
US7389355B2 (en) Customer access solutions architecture
US7177909B2 (en) Method and system for content driven electronic messaging
US20050004885A1 (en) Document/form processing method and apparatus using active documents and mobilized software
US20030120593A1 (en) Method and system for delivering multiple services electronically to customers via a centralized portal architecture
US20020107913A1 (en) System and method for rendering documents in a user-familiar format
US20020107752A1 (en) System and method for integrating web-originated orders with backend business systems
US8787616B2 (en) Document processing system and method
US20020107699A1 (en) Data management system and method for integrating non-homogenous systems
CA2293764C (en) System and method for presenting and processing documents on the internet
US20110170136A1 (en) System and method for certifying and authenticating correspondence (ii)
AU2003249755B2 (en) A bulk communications process using multiple delivery media
WO2006118572A1 (en) Document/form processing method and apparatus using active documents and mobilized software
AU2002229416B2 (en) Method of and system for trackable electronic delivery for invoices
JP2002324072A (ja) 文書管理システムおよび文書管理方法
JPWO2008129630A1 (ja) 情報管理システム、プログラム、および情報管理方法

Legal Events

Date Code Title Description
N231 Notification of change of applicant
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application