KR20220051131A - 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링 - Google Patents

다중 도메인 네트워크에서 중앙 집중식 상태 모니터링 Download PDF

Info

Publication number
KR20220051131A
KR20220051131A KR1020217020358A KR20217020358A KR20220051131A KR 20220051131 A KR20220051131 A KR 20220051131A KR 1020217020358 A KR1020217020358 A KR 1020217020358A KR 20217020358 A KR20217020358 A KR 20217020358A KR 20220051131 A KR20220051131 A KR 20220051131A
Authority
KR
South Korea
Prior art keywords
domain
request
status
order
mdr
Prior art date
Application number
KR1020217020358A
Other languages
English (en)
Other versions
KR102549317B1 (ko
Inventor
스브라흐마니야 프라모드 난두리
수윤 맥마스터
다린 밀러
케니 시
Original Assignee
쿠팡 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쿠팡 주식회사 filed Critical 쿠팡 주식회사
Priority to KR1020237021497A priority Critical patent/KR20230101937A/ko
Publication of KR20220051131A publication Critical patent/KR20220051131A/ko
Application granted granted Critical
Publication of KR102549317B1 publication Critical patent/KR102549317B1/ko

Links

Images

Classifications

    • 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
    • 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/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • 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/02—Reservations, e.g. for tickets, services or events
    • 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
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1895—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for short real-time information, e.g. alarms, notifications, alerts, updates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/12—Discovery or management of network topologies

Abstract

다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 시스템이다. 시스템은 실행될 때 프로세서가 동작을 수행하도록 구성하는 명령어를 저장하는 적어도 하나의 프로세서 및 적어도 하나의 메모리 디바이스를 포함한다. 동작은 도메인과의 연결을 설정하고, 모니터링 동작을 시작하기 위해 제1 도메인으로부터 제1요청을 수신하고, 제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하는 것을 포함한다. 동작은 또한 모니터링 동작을 업데이트하기 위해 제2 도메인으로부터 제2 요청을 수신하고, 제2 요청을 수신하는 것에 응답하여, 상태 필드를 수정함으로써 상태 테이블에 새로운 엔트리를 업데이트하는 것을 포함할 수 있다.동작은 또한 모니터링 엔진으로부터 제3요청을 수신하는 것에 응답하여 모니터 동작을 적용하고 상태 필드가 카테고리 상태와 일치하는 상태 테이블의 엔트리를 포함하는 경보를 생성하는 것을 포함할 수 있다.

Description

다중 도메인 네트워크에서 중앙 집중식 상태 모니터링
본 개시는 일반적으로 다중 도메인 네트워크에서 중앙 집중식 모니터링을 위한 컴퓨터화된 시스템 및 방법에 관한 것이다. 특히, 본 개시의 실시예는 중앙 집중식 데이터베이스 및 브로드캐스트 경보를 동적으로 업데이트하기 위해 분산된 하이퍼 미디어 통신을 이용하여 다중 도메인 네트워크를 통해 주문 또는 티켓의 상태를 모니터링 하기 위한 시스템 및 방법과 관련된다.
다수의 위치, 부서 및/또는 사업 부문이 있는 회사 및 조직은 내부 및 외부 통신을 제어, 모니터링 및 구성하기 위해 다수의 도메인(다중 도메인 네트워크라고도 함)이 있는 네트워크를 자주 활용한다. 회사는 일반적으로 리소스를 효과적으로 할당하고 작업을 할당하기 위해 다수의 도메인으로 네트워크를 구성한다. 또한, 다수의 도메인 토폴로지를 이용하여 네트워크 관리자가 통신을 보다 효율적으로 모니터링하고 제어할 수 있게 한다. 예를 들어, 다중 도메인 네트워크는 수신 및 발신 트래픽이 분산되기 전에 필터링, 라우팅 및 스캔하는 도메인 관리자를 이용하여 계층적 통신 제어의 이용이 가능하게 한다.
오늘날 네트워크는 복잡한 그리드에서 서로 결합된 다수의 도메인으로 자주 구성되고 복잡한 워크 플로우를 구현하도록 구성된다. 예를 들어, 네트워크는 통신 및 리소스를 구성하기 위해 보안, 데이터 센터 및 고객 대면 도메인에서 자주 분리된다. 그러나, 이러한 도메인은 긴밀하게 링크되어 있으며 자주 실시간으로 서로 상호 작용한다. 그리고 도메인 간 상호 작용은 적절한 사용자 경험을 제공하기 위해 빠르고 오류가 없으며 안전해야 한다.
복잡한 네트워크 토폴로지와 고성능 요구의 조합은 다중 도메인 네트워크를 개발하고 관리하는 데 어려움을 겪었다. 동일한 네트워크 내의 도메인이 독립적이고 전문화된 토폴로지를 가질 수 있기 때문에 대규모 다중 도메인 네트워크를 관리하는 것은 복잡하다. 또한, 네트워크의 도메인은 서로 다른 리소스의 분포, 비 균일 프로토콜 또는 일관성 없는 네트워크 구성을 가질 수 있다. 더욱이, 실시간 도메인 간 상호 작용의 요건은 통신을 방해하거나 지연시킬 수 있는 특정 관리 동작을 자주 방해한다. 관리 동작에 대한 권한이 부족한 방대한 여러 가지 도메인 구성, 토폴로지 및 프로토콜(단일 네트워크 내에서도)의 조합은, 다중 도메인 네트워크를 효과적으로 관리하는데 중요한 기술적 문제를 야기했다.
다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 개시된 시스템 및 방법은 전술된 하나 이상의 문제 및/또는 종래 기술의 다른 문제를 해결한다.
본 개시의 한 양상은 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 시스템에 관한 것이다. 시스템은 적어도 하나의 프로세서 및 실행될 때 적어도 하나의 프로세서가 동작을 수행하도록 구성하는 명령을 포함하는 적어도 하나의 메모리 디바이스를 포함할 수 있다. 동작은 제1 도메인 및 제2 도메인과의 연결을 설정하고, 모니터링 동작을 개시하기 위해 제1 도메인으로부터 제1 요청을 수신하고 (제1 요청은 생성 요청을 포함함), 제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고, 상태 테이블은 (1) ID 필드, (2) 예상 종료 필드 및 (3) 상태 필드를 포함한다. 동작은 또한 모니터링 동작을 업데이트하기 위해 제2 도메인으로부터 제2 요청을 수신하고, 제2 요청은 업데이트 상태 요청을 포함하고, 제2 요청을 수신하는 것에 응답하여, 상태 필드를 수정하여 상태 테이블의 새로운 엔트리를 업데이트하는 것을 포함할 수 있다. 또한, 동작은 모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 (제3 요청은 리포트 요청 및 카테고리 상태를 포함함), 모니터링 엔진은 주기적으로 제3 요청을 생성하도록 구성되고, 상태 필드가 카테고리 상태와 일치하는 상태 테이블의 엔트리를 포함하는 경보를 생성하는 것을 포함할 수 있다.
본 개시의 다른 양상은 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 컴퓨터-구현 방법에 관한 것이다. 방법은 제1 도메인 및 제2 도메인과의 연결을 설정하고, 모니터링 동작을 개시하기 위해 제1 도메인으로부터 제1 요청을 수신하고, 제1 요청은 생성 요청을 포함하고, 제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고, 상태 테이블은 (1) ID 필드, (2) 예상 종료 필드 및 (3) 상태 필드를 포함한다. 방법은 또한 모니터링 동작을 업데이트하기 위해 제2 도메인으로부터 제2 요청을 수신하고, 제2 요청은 업데이트 상태 요청을 포함하고, 제2 요청을 수신하는 것에 응답하여, 상태 필드를 수정하여 상태 테이블의 새로운 엔트리를 업데이트하는 것을 포함할 수 있다. 또한, 방법은 모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 (제3 요청은 리포트 요청 및 카테고리 상태를 포함함), 모니터링 엔진은 주기적으로 제3 요청을 생성하도록 구성되고, 상태 필드가 카테고리 상태와 일치하는 상태 테이블의 엔트리를 포함하는 경보를 생성하는 것을 포함할 수 있다.
본 개시의 또 다른 양상은 장치에 관한 것이다. 장치는 하나 이상의 프로세서 및 실행될 때 하나 이상의 프로세서가: 자동화된 디스커버리 동작을 수행하여 제1 도메인 및 제2 도메인과의 연결을 설정하도록 구성하는 명령을 포함하는 하나 이상의 메모리 디바이스를 포함한다. 자동화된 디스커버리는 제1 도메인 및 제2 도메인과 연관된 구성 템플릿을 자동으로 디스커버링 하고, 새로운 주문이 수신되거나 주문이 풀필먼트 센터로 전송될 때 생성 요청을 생성하도록 (제1 도메인과 연관된 하나 이상의 웹 API를 통해) 제1 도메인을 구성하고, 그리고 아이템이 배송될 때 업데이트 요청을 생성하기 위해, 제2 도메인과 연관된 하나 이상의 웹 API를 통해, 제2 도메인을 구성하는 것을 포함한다. 명령은 적어도 하나의 프로세서가 모니터링 동작을 개시하기 위해 제1 도메인으로부터 제1 요청을 수신하고(제1 요청은 주문 키를 포함하는 제1 REST API 호출을 포함하고), 주문 키는 아이템 ID 및 벤더 ID를 인코딩 하도록 추가로 구성한다. 명령은 또한 적어도 하나의 프로세서가 제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고, 상태 테이블은 (1) ID 필드, (2) 예상 종료 필드 및 (3) 상태 필드를 포함하도록 구성할 수 있다. 명령은 적어도 하나의 프로세서가 모니터링 동작을 업데이트하기 위해 제2 도메인으로부터 제2 요청을 수신하고, 제2 요청은 배송 정보를 포함하는 제2 REST API 호출을 포함하고, 제2 요청을 수신하는 것에 응답하여, 상태 필드를 수정하여 상태 테이블의 새로운 엔트리를 업데이트 하도록 추가로 구성할 수 있다. 명령은 또한 적어도 하나의 프로세서가 모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 (제3 요청은 리포트 요청 및 카테고리 상태를 포함하고, 모니터링 엔진은 적어도 하루에 한 번 제3 요청을 생성하도록 구성되고, 모니터링 동작은 자동화된 서버를 통해 수행됨), 상태 필드의 값이 널 또는 누락된 PDD 중 적어도 하나 인 상태 테이블의 엔트리를 포함하는 관리자 네트워크에서 경고 이메일을 브로드 캐스팅 하도록 구성할 수 있다.
도 1a는 개시된 실시예에 따른, 배송, 운송, 및 물류 운영을 가능하게 하는 통신을 위한 컴퓨터 시스템을 포함하는 네트워크의 예시적인 실시예를 나타낸 개략적인 블록도이다.
도 1b는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 검색 요청을 만족시키는 하나 이상의 검색 결과를 포함하는 검색 결과 페이지(SRP; Search Result Page)의 샘플을 나타낸 도면이다.
도 1c는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 제품 및 제품에 대한 정보를 포함하는 싱글 디스플레이 페이지(SDP; Single Display Page)의 샘플을 나타낸 도면이다.
도 1d는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 가상의 쇼핑 장바구니에 아이템을 포함하는 장바구니 페이지의 샘플을 나타낸 도면이다.
도 1e는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라, 가상의 쇼핑 장바구니로부터 구매 및 배송에 관한 정보에 따른 아이템을 포함하는 주문 페이지의 샘플을 나타낸 도면이다.
도 2는 개시된 실시예에 따른, 개시된 컴퓨터 시스템을 활용하도록 구성된 예시적인 풀필먼트 센터의 개략적인 도면이다.
도 3은 개시된 실시예에 따른, 예시적인 시스템의 개략적인 블록도이다.
도 4는 개시된 실시예에 따른, 예시적인 클라이언트 디바이스의 블록도이다.
도 5는 개시된 실시예에 따른, 예시적인 데이터베이스의 블록도이다.
도 6은 개시된 실시예에 따른, 예시적인 다중 도메인 리포팅(MDR) 시스템의 블록도이다.
도 7은 개시된 실시예에 따른, MDR 시스템을 포함하는 다중 도메인 네트워크의 블록도이다.
도 8은 개시된 실시예에 따른, MDR 서비스로 주문 배송을 모니터링 하기 위한 예시적인 프로세스의 흐름도이다.
도 9는 개시된 실시예에 따른, 자동화된 디스커버리(discovery) 동작을 통해 다중 도메인 네트워크에서 복수의 도메인들과의 통신을 구성하기 위한 예시적인 프로세스 흐름의 타이밍도이다.
도 10은 개시된 실시예에 따른, 도메인 요청을 처리하고 경보를 생성하기 위한 예시적인 프로세스 흐름의 타이밍도이다.
도 11은 개시된 실시예에 따른, 데이터베이스에 저장된 다중 도메인 모니터링을 위한 예시적인 상태 테이블이다.
도 12는 개시된 실시예에 따른, 다중 도메인 상태 모니터링을 위한 예시적인 프로세스의 흐름도이다.
도 13은 개시된 실시예에 따른, 자동화된 디스커버리 연결을 통해 다중 도메인 통신을 설정하기 위한 예시적인 프로세스의 흐름도이다.
도 14는 개시된 실시예에 따른, 다중 도메인 상태 테이블에서 모니터링 엔티티를 관리하기 위한 예시적인 프로세스의 흐름도이다.
도 15는 개시된 실시예에 따른, 풀필먼트 센터의 할당 및 약속된 배달 날짜(PDD)를 결정하기 위한 예시적인 프로세스의 흐름도이다.
도 16은 개시된 실시예에 따른, 다중 도메인 네트워크에서의 주문에 대한 예시적인 상태 결정 프로세스를 설명하는 상태 머신 다이어그램이다.
도 17은 개시된 실시예에 따른, 관리자 네트워크를 통해 전송된 경보를 보여주는 그래픽 사용자 인터페이스이다.
이어서 첨부된 도면을 참조하여 자세하게 설명된다. 가능하면, 다음의 설명에서 같거나 유사한 부분에 대해 참조되도록 도면에서 같은 도면 부호가 사용된다. 여기에 몇몇 예시적인 실시예가 설명되지만, 변경, 조정 및 다른 구현도 가능하다. 예를 들면, 도면 내의 구성 및 스텝에 대해 교체, 추가, 또는 변경이 이루어질 수 있고, 여기에 설명된 예시적인 방법은 개시된 방법에 대해 스텝을 교체, 순서 변경, 제거 또는 추가함으로써 변경될 수 있다. 다음의 자세한 설명은 개시된 실시예 및 예시로 제한되는 것은 아니다. 대신에 본 발명의 적절한 범위는 청구범위에 의해 규정된다.
본 개시의 실시예는 연결 해제된 워크 플로우를 수행하는 다중 도메인 네트워크에서 주문 또는 티켓 상태 모니터링을 위한 시스템 및 방법에 관한 것이다. 개시된 시스템 및 방법은 다중 도메인 네트워크 전체에서 동작의 진행 상황을 추적하는 자동화되고 중앙 집중식 리포팅 시스템을 생성함으로써 다중 도메인 네트워크를 통한 모니터링 동작의 기술 분야를 개선할 수 있다. 개시된 시스템은, 이벤트 및/또는 다른 도메인 간 통신에 의해 트리거 되는, 업데이트 메시지를 자동으로 전송하도록 다중 도메인 네트워크에서 디바이스의 프로그래밍을 추가로 허용할 수 있다. 따라서, 개시된 중앙 집중식 모니터링을 위한 시스템 및 방법은 전체 네트워크 걸쳐 연결 해제된 워크 플로를 모니터링 하고 관리자가 상태를 식별하고 리포트를 제공할 수 있게 하는 균일한 상태 변수를 제공하는 이벤트를 저장하는 중앙 집중식 데이터베이스를 생성함으로써 다중 도메인 네트워크 관리의 기술 분야를 개선할 수 있다.
개시된 시스템 및 방법의 일부 실시예는 전자 상거래 네트워크에서 주문을 모니터링 하는 문제를 해결한다. 예를 들어, 개시된 시스템은, 현재 처리 도메인에 관계없이, 실시간으로 고객 주문의 상태를 모니터링 할 수 있다. 개시된 시스템의 이러한 실시예는 네트워크 관리자 또는 관리자가 누락된 약속된 배달 날짜(PDD), 잘못된 예상된 배달 날짜 또는 지연을 식별함으로써 주문 또는 티켓의 상태를 쉽게 식별할 수 있도록 할 수 있게 한다. 따라서, 개시된 시스템 및 방법은 모니터링 동작을 자동화하고 중단된 워크 플로의 빠른 식별 및 해결을 가능하게 함으로써 다중 도메인 네트워크 관리의 기술 분야를 개선할 수 있다.
개시된 시스템 및 방법의 일부 실시예는 특히 다중 도메인 네트워크에 기초한 자동화된 배송의 시스템을 개선할 수 있다. 연결 해제된 다수의 워크 플로우는 구매, 주문 및 배송 워크 플로우를 포함하여, 주문 이행 프로세스에 참여한다. 이러한 워크 플로우는 서로 연결될 수 있지만 그것들 자신의 속도와 서로 다른 도메인에서 실행될 수 있다. 예를 들어, 주문 처리는 주문 배송과는 독립적인 도메인에서 처리될 수 있다. 개시된 시스템 및 방법은 다수의 도메인에 걸쳐 주문의 상태를 모니터링하고 머신-러닝 모델에 기초하여 예측을 수행하는 도구를 제공할 수 있다. 예를 들어, 중앙 집중식 데이터베이스에서 수집 및 정규화된 데이터는 관리자가 주문 또는 티켓 지연을 예측할 수 있게 하는 예측 머신-러닝(ML) 모델을 트레이닝 하는데 이용될 수 있다. 따라서, 개시된 시스템 및 방법은 또한 예측 및 분석 도구를 제공함으로써 다중 도메인 네트워크의 관리를 개선할 수 있다.
또한, 개시된 시스템 및 방법의 일부 실시예는 예상된 배달 날짜 또는 약속된 배달 날짜(PDD)를 놓친(또는 놓칠) 주문을 식별하기 위해 다중 도메인 네트워크에서 고객 주문을 모니터링 하는 문제를 해결하는데 적용될 수 있다. 그러나, 주문 배달 모니터링 외에, 개시 시스템 및 방법의 실시 예는 다중 도메인 네트워크에서 주문 구매 또는 재고를 모니터링 할 수 있다.
더욱이, 개시된 시스템 및 방법은 또한 도메인 간 통신을 자동으로 구성하는 자동화된 디스커버리 동작을 수행하는 도구를 제공함으로써 다중 도메인 네트워크를 구성하는 기술 분야를 개선할 수 있다. 예를 들어, 일부 실시예에서 개시된 시스템 및 방법은, REST(Representational State Transfer) 호출과 같은, 표준화된 웹 기반 통신 방안을 이용함으로써 다수의 도메인을 중앙 집중식 리포팅 시스템에 연결하기 위한 도구를 제공할 수 있으며, 마인스톤(milestones) 또는 특정 이벤트에 의해 트리거 되는 자동화된 통신을 전송하도록 도메인을 구성할 수 있다. 개시된 시스템 및 방법의 이러한 실시예는 다중 도메인 네트워크에서 균일성 및/또는 관리 권한의 부족 문제를 해결할 수 있다.
개시된 시스템 및 방법의 실시예는 또한 자동화된 디스커버리를 통해 모니터링 되는 도메인의 그룹을 원활하게 확장하기 위한 도구를 생성함으로써 다중 도메인 네트워크에서 모니터링 시스템을 구성하는 기술적 문제를 해결할 수 있다. 예를 들어, 개시된 시스템 및 방법은 추가 모니터링 엔티티를 생성하거나 추가 리포팅 통신을 위한 도메인을 구성하기 위해, 다중 도메인 네트워크에서 새로운 도메인을 자동으로 식별하거나, 네트워크의 새로운 동작을 식별하는, 도구를 제공할 수 있다. 개시된 시스템 및 방법의 이러한 실시예는 네트워크에서 통신 패턴을 식별하고 그에 따라 모니터링 데이터베이스를 조정하기 위해 ML 알고리즘을 적용하는 것을 포함할 수 있다.
추가적으로, 개시된 시스템 및 방법의 실시예는 비정상 시나리오 및/또는 지연을 자동으로 모니터링 함으로써 다중 도메인 시스템의 관리를 개선할 수 있다. 예를 들어, 개시된 시스템 및 방법은, 상태 요청에 대한 응답을 제공하고/하거나 경보, 작업 및/또는 주문을 생성하는, 균일한 리포팅 시스템처럼 작동하는, 통합된 및 중앙 집중식 상태 모니터링 데이터베이스를 제공할 수 있다. 그러한 실시예는, 실시간 및/또는 주기적으로 질의 될 수 있는 리포팅 서비스를 생성하여 주문 또는 티켓 상태의 면밀한 모니터링을 가능하게 함으로써 다중 도메인 시스템의 관리를 용이하게 할 수 있다. 개시된 시스템 및 방법의 이러한 실시예는 지연을 식별하고 해결하기 위해 연결 해제된 워크 플로우를 자동으로 조정할 수 있게 한다. 또한, 그러한 실시예는 상태 모니터링의 주문형 질의를 위한 REST 서비스를 제공함으로써 다중 도메인 네트워크의 관리를 개선할 수도 있다.
개시된 시스템 및 방법의 실시예는 또한 다중 도메인 네트워크에서 이벤트를 모니터링 하기 위해 이용되는 트래픽을 감소시킴으로써 다중 도메인 네트워크에서 대역폭 활용을 개선할 수 있다. 개시된 시스템 및 방법의 일부 실시예는 연결 해제된 워크 플로우를 소수의 파라미터로 수렴하는 중앙 집중식 시스템에 대한 단순하고 표준화된 통신을 이용하여 감소된 오버 헤드로 서로 다른 연결 해제된 워크 플로우를 모니터링 하는 것을 허용할 수 있다. 이러한 실시예는 네트워크 혼잡을 최소화함으로써 다중 도메인 네트워크의 성능을 개선할 수 있다. 예를 들어, 개시된 시스템 및 방법은 상태 모니터링에 이용되는 통신을 감소, 정규화 및 단순화함으로써 네트워크 통신을 개선 할 수 있다.
이제 개시된 실시예를 참조할 것이며, 그 예는 첨부 도면에 도시되어 있다.
도 1a를 참조하면, 배송, 운송 및 물류 운영을 가능하게 하는 통신을 위한 컴퓨터 시스템을 포함하는 예시적인 시스템의 실시예를 나타낸 시스템(100)의 개략적인 블록도가 도시되어 있다. 도 1a에 나타낸 바와 같이, 시스템(100)은 다양한 시스템을 포함할 수 있으며, 이들 각각은 하나 이상의 네트워크를 통해 서로 연결될 수 있다. 시스템은 (예를 들어, 케이블을 사용한) 직접 연결을 통해 서로 연결될 수 있다. 도시된 시스템은 배송 기관 기술(shipment authority technology, SAT) 시스템(101), 외부 프론트 엔드 시스템(103), 내부 프론트 엔드 시스템(105), 운송 시스템(107), 모바일 디바이스(107A, 107B, 107C), 판매자 포털(109), 배송 및 주문 트래킹(shipment and order tracking, SOT) 시스템(111), 풀필먼트 최적화(fulfillment optimization, FO) 시스템(113), 풀필먼트 메시징 게이트웨이(fulfillment messaging gateway, FMG)(115), 공급 체인 관리(supply chain management, SCM) 시스템(117), 인력 관리 시스템(119), 모바일 디바이스(119A, 119B, 119C)(풀필먼트 센터(fulfillment center, FC)(200) 내부에 있는 것으로 도시됨), 제3자 풀필먼트 시스템(121A, 121B, 121C), 풀필먼트 센터 인증 시스템(fulfillment center authorization system, FC Auth)(123), 및 노동 관리 시스템(labor management system, LMS)(125)을 포함한다.
일부 실시예에서, SAT 시스템(101)은 주문 상태와 배달 상태를 모니터링하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, SAT 시스템(101)은 주문이 약속된 배달 날짜(Promised Delivery Date, PDD)를 지났는지를 결정할 수 있고, 새로운 주문을 개시시키고, 배달되지 않은 주문의 아이템을 다시 배송하며, 배달되지 않은 주문을 취소하고, 주문 고객과 연락을 시작하는 것 등을 포함하는 적합한 조치를 취할 수 있다. SAT 시스템(101)은 또한, (특정 기간 동안 배송된 패키지의 개수와 같은) 출력, 및 (배송시 사용하기 위해 수신된 빈 카드보드 박스의 개수와 같은) 입력을 포함하는 다른 데이터를 감시할 수 있다. SAT 시스템(101)은 또한, 외부 프론트 엔드 시스템(103) 및 FO 시스템(113)과 같은 장치들 간의 (예를 들면, 저장 전달(store-and-forward) 또는 다른 기술을 사용하는) 통신을 가능하게 하는 시스템(100) 내의 상이한 장치들 사이의 게이트웨이로서 동작할 수 있다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 외부 사용자가 시스템(100) 내의 하나 이상의 시스템과 상호 동작할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 시스템(100)이 시스템의 프레젠테이션을 가능하게 하여 사용자가 아이템에 대한 주문을 할 수 있도록 하는 실시예에서, 외부 프론트 엔드 시스템(103)은 검색 요청을 수신하고, 아이템 페이지를 제시하며, 결제 정보를 요청하는 웹 서버로서 구현될 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 Apache HTTP 서버, Microsoft Internet Information Services(IIS), NGINX 등과 같은 소프트웨어를 실행하는 컴퓨터 또는 컴퓨터들로서 구현될 수 있다. 다른 실시예에서, 외부 프론트 엔드 시스템(103)은 외부 디바이스(예를 들어, 모바일 디바이스(102A) 또는 컴퓨터(102B))로부터 요청을 수신 및 처리하고, 이들 요청에 기초하여 데이터베이스 및 다른 데이터 저장 장치로부터 정보를 획득하며, 획득한 정보에 기초하여 수신된 요청에 대한 응답을 제공하도록 설계된 커스텀 웹 서버 소프트웨어를 실행할 수 있다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 웹 캐싱 시스템, 데이터베이스, 검색 시스템, 또는 결제 시스템 중 하나 이상을 포함할 수 있다. 일 양상에서, 외부 프론트 엔드 시스템(103)은 이들 시스템 중 하나 이상을 포함할 수 있는 반면, 다른 양상에서는 외부 프론트 엔드 시스템(103)은 이들 시스템 중 하나 이상에 연결된 인터페이스(예를 들면, 서버 대 서버, 데이터베이스 대 데이터베이스, 또는 다른 네트워크 연결)를 포함할 수 있다.
도 1b, 1c, 1d 및 1e에 의해 나타낸 단계들의 예시적인 세트는 외부 프론트 엔드 시스템(103)의 일부 동작을 설명하는 것에 도움이 될 것이다. 외부 프론트 엔드 시스템(103)은 프레젠테이션 및/또는 디스플레이를 위해 시스템(100) 내의 시스템 또는 디바이스로부터 정보를 수신할 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 검색 결과 페이지(Search Result Page, SRP)(예를 들면, 도 1b), 싱글 디스플레이 페이지(Single Display Page, SDP)(예를 들면, 도 1c), 장바구니 페이지(Cart page)(예를 들면, 도 1d), 또는 주문 페이지(예를 들면, 도 1e)를 포함하는 하나 이상의 웹페이지를 호스팅하거나 제공할 수 있다. (예를 들면, 모바일 디바이스(102A) 또는 컴퓨터(102B)를 사용하는) 사용자 디바이스는 외부 프론트 엔드 시스템(103)으로 이동하고 검색 박스에 정보를 입력함으로써 검색을 요청할 수 있다. 외부 프론트 엔드 시스템(103)은 시스템(100) 내의 하나 이상의 시스템으로부터 정보를 요청할 수 있다. 예를 들면, 외부 프론트 엔드 시스템(103)은 FO 시스템(113)으로부터 검색 요청을 만족하는 정보를 요청할 수 있다. 외부 프론트 엔드 시스템(103)은 또한, (FO 시스템(113)으로부터) 검색 결과에 포함된 각 제품에 대한 약속된 배달 날짜(Promised Delivery Date) 또는 "PDD"를 요청하고 수신할 수 있다. 일부 실시예에서, PDD는 제품이 들어있는 패키지가 특정 기간 이내, 예를 들면, 하루의 끝(PM 11:59)까지 주문되면 언제 사용자가 원하는 장소에 도착할 것인지에 대한 추정 또는 제품이 사용자가 원하는 장소에 배달될 약속된 날짜를 나타낼 수 있다(PDD는 FO 시스템(113)과 관련하여 이하에서 더 논의된다).
외부 프론트 엔드 시스템(103)은 정보에 기초하여 SRP(예를 들면, 도 1b)를 준비할 수 있다. SRP는 검색 요청을 만족하는 정보를 포함할 수 있다. 예를 들면, 이는 검색 요청을 만족하는 제품의 사진을 포함할 수 있다. SRP는 또한, 각 제품에 대한 각각의 가격, 또는 각 제품, PDD, 무게, 크기, 오퍼(offer), 할인 등에 대한 개선된 배달 옵션에 관한 정보를 포함할 수 있다. 일부 실시예에서, SRP는 또한 배달 옵션, 배달 옵션의 컷오프 시간 및/또는 사용자 입력을 요청하는 하이퍼미디어 요소를 포함할 수 있다. 외부 프론트 엔드 시스템(103)은 (예를 들면, 네트워크를 통해) SRP를 요청 사용자 디바이스로 전송할 수 있다.
사용자 디바이스는 SRP에 나타낸 제품을 선택하기 위해, 예를 들면, 사용자 인터페이스를 클릭 또는 탭핑하거나, 다른 입력 디바이스를 사용하여 SRP로부터 제품을 선택할 수 있다. 사용자 디바이스는 선택된 제품에 관한 정보에 대한 요청을 만들어 내고 이를 외부 프론트 엔드 시스템(103)으로 전송할 수 있다. 이에 응답하여, 외부 프론트 엔드 시스템(103)은 선택된 제품에 관한 정보를 요청할 수 있다. 예를 들면, 정보는 각각의 SRP 상에 제품에 대해 제시된 것 이상의 추가 정보를 포함할 수 있다. 이는, 예를 들면, 유통 기한, 원산지, 무게, 크기, 패키지 내의 아이템 개수, 취급 지침, 새벽 또는 최초 배달에 대한 컷오프 시간, 또는 제품에 대한 다른 정보를 포함할 수 있다. 정보는 또한, (예를 들면, 이 제품 및 적어도 하나의 다른 제품을 구입한 고객의 빅 데이터 및/또는 기계 학습 분석에 기초한) 유사한 제품에 대한 추천, 자주 묻는 질문에 대한 답변, 고객의 후기, 제조 업체 정보, 사진 등을 포함할 수 있다.
외부 프론트 엔드 시스템(103)은 수신된 제품 정보, 고객 디바이스의 위치 및 배달 옵션의 가용성에 기초하여 SDP(Single Dispaly Page)(예를 들면, 도 1c)를 준비할 수 있다. SDP는 또한, "지금 구매(Buy Now)" 버튼, "장바구니에 추가(Add to Cart)" 버튼, 수량 필드, 아이템 사진 등과 같은 다른 상호 동작 요소를 포함할 수 있다. SDP는 제품을 오퍼하는 판매자의 리스트를 포함할 수 있다. 이 리스트는 최저가로 제품을 판매하는 것으로 오퍼하는 판매자가 리스트의 최상단에 위치하도록, 각 판매자가 오퍼한 가격에 기초하여 순서가 정해질 수 있다. 이 리스트는 또한 최고 순위 판매자가 리스트의 최상단에 위치하도록, 판매자 순위에 기초하여 순서가 정해질 수 있다. 판매자 순위는, 예를 들어, 약속된 PPD를 지켰는지에 대한 판매자의 과거 추적 기록을 포함하는, 복수의 인자에 기초하여 만들어질 수 있다. 외부 프론트 엔드 시스템(103)은 (예를 들면, 네트워크를 통해) SDP를 요청 사용자 디바이스로 전달할 수 있다.
요청 사용자 디바이스는 제품 정보를 나열하는 SDP를 수신할 수 있다. SDP를 수신하면, 사용자 디바이스는 SDP와 상호 동작할 수 있다. 예를 들면, 요청 사용자 디바이스의 사용자는 SDP의 "장바구니에 담기(Place in Cart)" 버튼을 클릭하거나, 이와 상호 동작할 수 있다. 이렇게 하면 사용자와 연계된 쇼핑 장바구니에 제품이 추가된다. 대안적으로, 또는 추가적으로, 사용자는 배달을 위한 명령을 제공함으로써 SDP와 상호 작용할 수 있다. 사용자 디바이스는 제품을 쇼핑 장바구니에 추가하기 위해 외부 프론트 엔드 시스템(103)으로 이러한 요청을 전송할 수 있다.
외부 프론트 엔드 시스템(103)은 장바구니 페이지(예를 들면, 도 1d)를 생성할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 가상의 "쇼핑 장바구니(shopping cart)"에 추가한 제품을 나열한다. 사용자 디바이스는 SRP, SDP, 또는 다른 페이지의 아이콘을 클릭하거나, 상호 동작함으로써 장바구니 페이지를 요청할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 장바구니에 추가한 모든 제품 뿐 아니라 각 제품의 수량, 각 제품의 품목당 가격, 관련 수량에 기초한 각 제품의 가격, PDD에 관한 정보, 배달 방법, 배송 비용, 쇼핑 장바구니의 제품을 수정(예를 들면, 수량의 삭제 또는 수정)하기 위한 사용자 인터페이스 요소, 다른 제품의 주문 또는 제품의 정기적인 배달 설정에 대한 옵션, 할부(interest payment) 설정에 대한 옵션, 구매를 진행하기 위한 사용자 인터페이스 요소 등과 같은 장바구니의 제품에 관한 정보를 나열할 수 있다. 사용자 디바이스의 사용자는 쇼핑 장바구니에 있는 제품의 구매를 시작하기 위해 사용자 인터페이스 요소(예를 들면, "지금 구매(Buy Now)"라고 적혀있는 버튼)를 클릭하거나, 이와 상호 동작할 수 있다. 그렇게 하면, 사용자 디바이스는 구매를 시작하기 위해 이러한 요청을 외부 프론트 엔드 시스템(103)으로 전송할 수 있다. 일부 실시예에서, 카트 페이지는 각 제품 배달에 대한 텍스트 박스 입력, 대화 형 아이콘 또는 추천 메시지를 포함할 수 있다.
외부 프론트 엔드 시스템(103)은 구매를 시작하는 요청을 수신하는 것에 응답하여 주문 페이지(예를 들면, 도 1e)를 생성할 수 있다. 일부 실시예에서, 주문 페이지는 쇼핑 장바구니로부터의 아이템을 재나열하고, 결제 및 배송 정보의 입력을 요청한다. 예를 들면, 주문 페이지는 쇼핑 장바구니의 아이템 구매자에 관한 정보(예를 들면, 이름, 주소, 이메일 주소, 전화번호), 수령인에 관한 정보(예를 들면, 이름, 주소, 전화번호, 배달 정보), 배송 정보(예를 들면, 배달 및/또는 픽업 속도/방법), 결제 정보(예를 들면, 신용 카드, 은행 송금, 수표, 저장된 크레딧), 현금 영수증을 요청하는 사용자 인터페이스 요소(예를 들면, 세금 목적) 등을 요청하는 섹션을 포함할 수 있다. 외부 프론트 엔드 시스템(103)은 사용자 디바이스에 주문 페이지를 전송할 수 있다.
사용자 디바이스는 주문 페이지에 정보를 입력하고 외부 프론트 엔드 시스템(103)으로 정보를 전송하는 사용자 인터페이스 요소를 클릭하거나, 상호 동작할 수 있다. 그로부터, 외부 프론트 엔드 시스템(103)은 정보를 시스템(100) 내의 다른 시스템으로 전송하여 쇼핑 장바구니의 제품으로 새로운 주문을 생성하고 처리할 수 있도록 한다.
일부 실시예에서, 외부 프론트 엔드 시스템(103)은 판매자가 주문과 관련된 정보를 전송 및 수신할 수 있도록 추가로 구성될 수 있다.
일부 실시예에서, 내부 프론트 엔드 시스템(105)은 내부 사용자(예를 들면, 시스템(100)을 소유, 운영 또는 임대하는 조직의 직원)가 시스템(100) 내의 하나 이상의 시스템과 상호작용할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, SAT 시스템(101)이 사용자가 아이템에 대한 주문을 할 수 있게 하는 시스템의 프레젠테이션을 가능하게 하는 실시예에서, 내부 프론트 엔드 시스템(105)은 내부 사용자가 주문에 대한 진단 및 통계 정보를 볼 수 있게 하고, 아이템 정보를 수정하며, 또는 주문에 대한 통계를 검토할 수 있게 하는 웹 서버로서 구현될 수 있다. 예를 들면, 내부 프론트 엔드 시스템(105)은 Apache HTTP 서버, Microsoft Internet Information Services(IIS), NGINX 등과 같은 소프트웨어를 실행하는 컴퓨터 또는 컴퓨터들로서 구현될 수 있다. 다른 실시예에서, 내부 프론트 엔드 시스템(105)은 (도시되지 않은 다른 디바이스뿐 아니라) 시스템(100) 내에 나타낸 시스템 또는 디바이스로부터 요청을 수신 및 처리하고, 그러한 요청에 기초하여 데이터베이스 및 다른 데이터 저장 장치로부터 정보를 획득하며, 획득한 정보에 기초하여 수신된 요청에 대한 응답을 제공하도록 (설계된 커스텀 웹 서버 소프트웨어를 실행)할 수 있다.
일부 실시예에서, 내부 프론트 엔드 시스템(105)은 웹 캐싱 시스템, 데이터베이스, 검색 시스템, 결제 시스템, 분석 시스템, 주문 모니터링 시스템 등 중 하나 이상을 포함할 수 있다. 일 양상에서, 내부 프론트 엔드 시스템(105)은 이들 시스템 중 하나 이상을 포함할 수 있는 반면, 다른 양상에서는 내부 프론트 엔드 시스템(105)은 이들 시스템 중 하나 이상에 연결된 인터페이스(예를 들면, 서버 대 서버, 데이터베이스 대 데이터베이스, 또는 다른 네트워크 연결)를 포함할 수 있다.
일부 실시예에서, 운송 시스템(107)은 시스템(100) 내의 시스템 또는 디바이스와 모바일 디바이스(107A-107C) 간의 통신을 가능하게 하는 컴퓨터 시스템으로서 구현될 수 있다. 일부 실시예에서, 운송 시스템(107)은 하나 이상의 모바일 디바이스(107A-107C)(예를 들면, 휴대 전화, 스마트폰, PDA 등)로부터 정보를 수신할 수 있다. 예를 들면, 일부 실시예에서, 모바일 디바이스(107A-107C)는 배달원에 의해 동작되는 디바이스를 포함할 수 있다. 정규직, 임시적 또는 교대 근무일 수 있는 배달원은 사용자에 의해 주문된 제품들이 들어 있는 패키지의 배달을 위해 모바일 디바이스(107A-107C)를 이용할 수 있다. 예를 들면, 패키지를 배달하기 위해, 배달원은 배달할 패키지와 배달할 위치를 나타내는 모바일 디바이스 상의 알림을 수신할 수 있다. 배달 장소에 도착하면, 배달원은 (예를 들면, 트럭의 뒤나 패키지의 크레이트에) 패키지를 둘 수 있고, 모바일 디바이스를 사용하여 패키지 상의 식별자와 관련된 데이터(예를 들면, 바코드, 이미지, 텍스트 문자열, RFID 태그 등)를 스캔하거나, 캡처하며, (예를 들면, 현관문에 놓거나, 경비원에게 맡기거나, 수령인에게 전달하는 것 등에 의해) 패키지를 배달할 수 있다. 일부 실시예에서, 배달원은 모바일 디바이스를 사용하여 패키지의 사진(들)을 찍거나 및/또는 서명을 받을 수 있다. 모바일 디바이스는, 예를 들면, 시간, 날짜, GPS 위치, 사진(들), 배달원에 관련된 식별자, 모바일 디바이스에 관련된 식별자 등을 포함하는 배달에 관한 정보를 포함하는 정보를 운송 시스템(107)에 전송할 수 있다. 운송 시스템(107)은 시스템(100) 내의 다른 시스템에 의한 접근을 위해 데이터베이스(미도시)에 이러한 정보를 저장할 수 있다. 일부 실시예에서, 운송 시스템(107)은 다른 시스템에 특정 패키지의 위치를 나타내는 트래킹 데이터를 준비 및 전송하기 위해 이러한 정보를 사용할 수 있다.
일부 실시예에서, 특정 사용자는, 한 종류의 모바일 디바이스를 사용할 수 있는 반면(예를 들면, 정규 직원은 바코드 스캐너, 스타일러스 및 다른 장치와 같은 커스텀 하드웨어를 갖는 전문 PDA를 사용할 수 있음), 다른 사용자는 다른 종류의 모바일 디바이스를 사용할 수 있다(예를 들면, 임시 또는 교대 근무 직원이 기성 휴대 전화 및/또는 스마트폰을 사용할 수 있음).
일부 실시예에서, 운송 시스템(107)은 사용자를 각각의 디바이스와 연관시킬 수 있다. 예를 들면, 운송 시스템(107)은 사용자(예를 들면, 사용자 식별자, 직원 식별자, 또는 전화번호에 의해 표현됨)와 모바일 디바이스(예를 들면, International Mobile Equipment Identity(IMEI), International Mobile Subscription Identifier(IMSI), 전화번호, Universal Unique Identifier(UUID), 또는 Globally Unique Identifier(GUID)에 의해 표현됨) 간의 연관성(association)을 저장할 수 있다. 운송 시스템(107)은, 다른 것들 중에 작업자의 위치, 작업자의 효율성, 또는 작업자의 속도를 결정하기 위해 데이터베이스에 저장된 데이터를 분석하기 위해 배달시 수신되는 데이터와 관련하여 이러한 연관성을 사용할 수 있다.
일부 실시예에서, 판매자 포털(109)은 판매자 또는 다른 외부 엔터티(entity)가 시스템(100) 내의 하나 이상의 시스템과 전자 통신할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 판매자는 판매자 포털(109)을 사용하여 시스템(100)을 통해 판매하고자 하는 제품에 대하여, 제품 정보, 주문 정보, 연락처 정보 등을 업로드하거나 제공하는 컴퓨터 시스템(미도시)을 이용할 수 있다.
일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 고객(예를 들면, 디바이스(102A-102B)를 사용하는 사용자)에 의해 주문된 제품들이 들어 있는 패키지의 위치에 관한 정보를 수신, 저장 및 포워딩하는 컴퓨터 시스템으로서 구현될 수 있다. 일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 고객에 의해 주문된 제품들이 들어 있는 패키지를 배달하는 배송 회사에 의해 운영되는 웹 서버(미도시)로부터 정보를 요청하거나 저장할 수 있다.
일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 시스템(100)에 나타낸 시스템들로부터 정보를 요청하고 저장할 수 있다. 예를 들면, 배송 및 주문 트래킹 시스템(111)은 운송 시스템(107)으로부터 정보를 요청할 수 있다. 전술한 바와 같이, 운송 시스템(107)은 하나 이상의 사용자(예를 들면, 배달원) 또는 차량(예를 들면, 배달 트럭)과 연관된 하나 이상의 모바일 디바이스(107A-107C)(예를 들면, 휴대 전화, 스마트폰, PDA 등)로부터 정보를 수신할 수 있다. 일부 실시예에서, 배송 및 주문 트래킹 시스템(111)은 또한, 풀필먼트 센터(예를 들면, 풀필먼트 센터(200)) 내부의 개별 제품의 위치를 결정하기 위해 인력 관리 시스템(WMS)(119)으로부터 정보를 요청할 수 있다. 배송 및 주문 트래킹 시스템(111)은 운송 시스템(107) 또는 WMS(119) 중 하나 이상으로부터 데이터를 요청하고, 이를 처리하며, 요청시 디바이스(예를 들면, 사용자 디바이스(102A, 102B))로 제공할 수 있다.
일부 실시예에서, 풀필먼트 최적화(FO) 시스템(113)은 다른 시스템(예를 들면, 외부 프론트 엔드 시스템(103) 및/또는 배송 및 주문 트래킹 시스템(111))으로부터의 고객 주문에 대한 정보를 저장하는 컴퓨터 시스템으로서 구현될 수 있다. FO 시스템(113)은 또한, 특정 아이템이 유지 또는 저장되는 곳을 나타내는 정보를 저장할 수 있다. 예를 들면, 소정 아이템은 하나의 풀필먼트 센터에만 저장될 수 있는 반면, 소정 다른 아이템은 다수의 풀필먼트 센터에 저장될 수 있다. 또 다른 실시예에서, 특정 풀필먼트 센터는 아이템의 특정 세트(예를 들면, 신선한 농산물 또는 냉동 제품)만을 저장하도록 구성될 수 있다. FO 시스템(113)은 이러한 정보뿐 아니라 관련 정보(예를 들면, 수량, 크기, 수령 날짜, 유통 기한 등)를 저장한다.
FO 시스템(113)은 또한, 각 제품에 대해 대응하는 PDD(약속된 배달 날짜)를 계산할 수 있다. 일부 실시예에서, PDD는 하나 이상의 요소에 기초할 수 있다. 예를 들면, FO 시스템(113)은 제품에 대한 과거 수요(예를 들면, 그 제품이 일정 기간 동안 얼마나 주문되었는지), 제품에 대한 예측된 수요(예를 들면, 얼마나 많은 고객이 다가오는 기간 동안 제품을 주문할 것으로 예상되는지), 일정 기간 동안 얼마나 많은 제품이 주문되었는지를 나타내는 네트워크 전반의 과거 수요, 다가오는 기간 동안 얼마나 많은 제품이 주문될 것으로 예상되는지를 나타내는 네트워크 전반의 예측된 수요, 각각의 제품을 저장하는 각 풀필먼트 센터(200)에 저장된 제품의 하나 이상의 개수, 그 제품에 대한 예상 또는 현재 주문 등에 기초하여 제품에 대한 PDD를 계산할 수 있다.
일부 실시예에서, 풀필먼트 메시징 게이트웨이(FMG)(115)는 FO 시스템(113)과 같은 시스템(100) 내의 하나 이상의 시스템으로부터 하나의 포맷 또는 프로토콜로 요청 또는 응답을 수신하고, 그것을 다른 포맷 또는 프로토콜로 변환하여, 변환된 포맷 또는 프로토콜로 된 요청 또는 응답을 WMS(119) 또는 제3자 풀필먼트 시스템(121A, 121B, 또는 121C)과 같은 다른 시스템에 포워딩하며, 반대의 경우도 가능한 컴퓨터 시스템으로서 구현될 수 있다.
일부 실시예에서, 공급 체인 관리(SCM) 시스템(117)은 예측 기능을 수행하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, SCM 시스템(117)은, 예를 들어 제품에 대한 과거 수요, 제품에 대한 예측된 수요, 네트워크 전반의 과거 수요, 네트워크 전반의 예측된 수요, 각각의 풀필먼트 센터(200)에 저장된 제품 개수, 각 제품에 대한 예상 또는 현재 주문 등에 기초하여, 특정 제품에 대한 수요의 수준을 예측할 수 있다. 이러한 예측된 수준과 모든 풀필먼트 센터를 통한 각 제품의 수량에 응답하여, SCM 시스템(117)은 특정 제품에 대한 예측된 수요를 만족시키기에 충분한 양을 구매 및 비축하기 위한 하나 이상의 구매 주문을 생성할 수 있다.
일부 실시예에서, 인력 관리 시스템(WMS)(119)은 작업 흐름을 모니터링하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, WMS(119)는 개개의 디바이스(예를 들면, 디바이스(107A-107C 또는 119A-119C))로부터 개별 이벤트를 나타내는 이벤트 데이터를 수신할 수 있다. 예를 들면, WMS(119)는 패키지를 스캔하기 위해 이들 디바이스 중 하나를 사용한 것을 나타내는 이벤트 데이터를 수신할 수 있다. 풀필먼트 센터(200) 및 도 2에 관하여 이하에서 논의되는 바와 같이, 풀필먼트 프로세스 동안, 패키지 식별자(예를 들면, 바코드 또는 RFID 태그 데이터)는 특정 스테이지의 기계(예를 들면, 자동 또는 핸드헬드 바코드 스캐너, RFID 판독기, 고속 카메라, 태블릿(119A), 모바일 디바이스/PDA(119B), 컴퓨터(119C)와 같은 디바이스 등)에 의해 스캔되거나 판독될 수 있다. WMS(119)는 패키지 식별자, 시간, 날짜, 위치, 사용자 식별자, 또는 다른 정보와 함께 대응하는 데이터베이스(미도시)에 패키지 식별자의 스캔 또는 판독을 나타내는 각 이벤트를 저장할 수 있고, 이러한 정보를 다른 시스템(예를 들면, 배송 및 주문 트래킹 시스템(111))에 제공할 수 있다.
일부 실시예에서, WMS(119)는 하나 이상의 디바이스(예를 들면, 디바이스(107A-107C 또는 119A-119C))와 시스템(100)과 연관된 하나 이상의 사용자를 연관시키는 정보를 저장할 수 있다. 예를 들면, 일부 상황에서, (파트 타임 또는 풀 타임 직원과 같은) 사용자는 모바일 디바이스(예를 들면, 모바일 디바이스는 스마트폰임)를 소유한다는 점에서, 모바일 디바이스와 연관될 수 있다. 다른 상황에서, 사용자는 임시로 모바일 디바이스를 보관한다는 점에서(예를 들면, 하루의 시작에서부터 모바일 디바이스를 대여받은 사용자가, 하루 동안 그것을 사용하고, 하루가 끝날 때 그것을 반납할 것임), 모바일 디바이스와 연관될 수 있다.
일부 실시예에서, WMS(119)는 시스템(100)과 연관된 각각의 사용자에 대한 작업 로그를 유지할 수 있다. 예를 들면, WMS(119)는 임의의 할당된 프로세스(예를 들면, 트럭에서 내리기, 픽업 구역에서 아이템을 픽업하기, 리비닝 월(rebin wall) 작업, 아이템 패킹하기), 사용자 식별자, 위치(예를 들면, 풀필먼트 센터(200)의 바닥 또는 구역), 직원에 의해 시스템을 통해 이동된 유닛의 수(예를 들면, 픽업된 아이템의 수, 패킹된 아이템의 수), 디바이스(예를 들면, 디바이스(119A-119C))와 관련된 식별자 등을 포함하는, 각 직원과 관련된 정보를 저장할 수 있다. 일부 실시예에서, WMS(119)는 디바이스(119A-119C)에서 작동되는 계시(timekeeping) 시스템과 같은 계시 시스템으로부터 체크-인 및 체크-아웃 정보를 수신할 수 있다.
일부 실시예에서, 제3자 풀필먼트(3PL) 시스템(121A-121C)은 물류 및 제품의 제3자 제공자와 관련된 컴퓨터 시스템을 나타낸다. 예를 들면, (도 2와 관련하여 이하에서 후술하는 바와 같이) 일부 제품이 풀필먼트 센터(200)에 저장되는 반면, 다른 제품은 오프-사이트(off-site)에 저장될 수 있거나, 수요에 따라 생산될 수 있으며, 달리 풀필먼트 센터(200)에 저장될 수 없다. 3PL 시스템(121A-121C)은 FO 시스템(113)으로부터 (예를 들면, FMG(115)를 통해) 주문을 수신하도록 구성될 수 있으며, 고객에게 직접 제품 및/또는 서비스(예를 들면, 배달 또는 설치)를 제공할 수 있다. 일부 구현예에서, 하나 이상의 3PL 시스템(121A-121C)은 시스템(100)의 일부일 수 있지만, 다른 구현예에서는, 하나 이상의 3PL 시스템(121A-121C)이 시스템(100)의 외부에 있을 수 있다(예를 들어, 제3자 제공자에 의해 소유 또는 운영됨)일 수 있다.
일부 실시예에서, 풀필먼트 센터 인증 시스템(FC Auth)(123)은 다양한 기능을 갖는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 일부 실시예에서, FC Auth(123)는 시스템(100) 내의 하나 이상의 다른 시스템에 대한 단일-사인 온(single-sign on, SSO) 서비스로서 작동할 수 있다. 예를 들면, FC Auth(123)는 내부 프론트 엔드 시스템(105)을 통해 사용자가 로그인하게 하고, 사용자가 배송 및 주문 트래킹 시스템(111)에서 리소스에 액세스하기 위해 유사한 권한을 갖고 있다고 결정하며, 두 번째 로그인 프로세스 요구 없이 사용자가 그러한 권한에 액세스할 수 있게 한다. 다른 실시예에서, FC Auth(123)는 사용자(예를 들면, 직원)가 자신을 특정 작업과 연관시킬 수 있게 한다. 예를 들면, 일부 직원은 (디바이스(119A-119C)와 같은) 전자 디바이스를 갖지 않을 수 있으며, 대신 하루 동안 풀필먼트 센터(200) 내에서 작업들 사이 및 구역들 사이에서 이동할 수 있다. FC Auth(123)는 이러한 직원들이 상이한 시간 대에 수행 중인 작업과 속해 있는 구역을 표시할 수 있도록 구성될 수 있다.
일부 실시예에서, 노동 관리 시스템(LMS)(125)은 직원(풀-타임 및 파트-타임 직원을 포함함)에 대한 출근 및 초과 근무 정보를 저장하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, LMS(125)는 FC Auth(123), WMA(119), 디바이스(119A-119C), 운송 시스템(107), 및/또는 디바이스(107A-107C)로부터 정보를 수신할 수 있다.
도 1a에 나타낸 특정 구성은 단지 예시일 뿐이다. 예를 들면, 도 1a는 FO 시스템(113)에 연결된 FC Auth 시스템(123)을 나타낸 반면, 모든 실시예가 이러한 특정 구성을 필요로 하는 것은 아니다. 실제로, 일부 실시예에서, 시스템(100) 내의 시스템은 인터넷, 인트라넷, WAN(Wide-Area Network), MAN(Metropolitan-Area Network), IEEE 802.11a/b/g/n 표준을 따르는 무선 네트워크, 임대 회선 등을 포함하는 하나 이상의 공공 또는 사설 네트워크를 통해 서로 연결될 수 있다. 일부 실시예에서, 시스템(100) 내의 시스템 중 하나 이상은 데이터 센터, 서버 팜 등에서 구현되는 하나 이상의 가상 서버로서 구현될 수 있다.
도 2는 풀필먼트 센터(200)를 나타낸다. 풀필먼트 센터(FC)(200)는 주문시 고객에게 배송하기 위한 아이템을 저장하는 물리적 장소의 예시이다. 풀필먼트 센터(FC)(200)는 다수의 구역으로 분할될 수 있으며, 각각이 도 2에 도시된다. 일부 실시예에서, 이러한 "구역(zones)"은 아이템을 수령하고, 아이템을 저장하고, 아이템을 검색하고, 아이템을 배송하는 과정의 상이한 단계 사이의 가상 구분으로 생각될 수 있다. 따라서, "구역"이 도 2에 나타나 있으나, 일부 실시예에서, 구역의 다른 구분도 가능하고, 도 2의 구역은 생략, 복제, 및/또는 수정될 수 있다.
인바운드 구역(203)은 시스템(100)(도 1a)을 사용하여 제품을 판매하고자 하는 판매자로부터 아이템이 수신되는 FC(200)의 영역을 나타낸다. 예를 들면, 판매자는 트럭(201)을 사용하여 아이템(202A, 202B)을 배달할 수 있다. 아이템(202A)은 자신의 배송 팔레트(pallet)를 점유하기에 충분히 큰 단일 아이템을 나타낼 수 있으며, 아이템(202B)은 공간을 절약하기 위해 동일한 팔레트 상에 함께 적층되는 아이템의 세트를 나타낼 수 있다.
작업자는 인바운드 구역(203)의 아이템을 수령하고, 선택적으로 컴퓨터 시스템(미도시)을 사용하여 아이템이 손상되었는지 및 정확한지를 체크할 수 있다. 예를 들면, 작업자는 아이템(202A, 202B)의 수량을 아이템의 주문 수량과 비교하기 위해 컴퓨터 시스템을 사용할 수 있다. 수량이 일치하지 않는다면, 해당 작업자는 아이템(202A, 202B) 중 하나 이상을 거부할 수 있다. 수량이 일치한다면, 작업자는 그 아이템들을 (예를 들면, 짐수레(dolly), 핸드트럭(handtruck), 포크리프트(forklift), 또는 수작업으로) 버퍼 구역(205)으로 운반할 수 있다. 버퍼 구역(205)은, 예를 들면, 예측된 수요를 충족시키기 위해 픽업 구역에 그 아이템이 충분한 수량만큼 있기 때문에, 픽업 구역에서 현재 필요하지 않은 아이템에 대한 임시 저장 영역일 수 있다. 일부 실시예에서, 포크리프트(206)는 버퍼 구역(205) 주위와 인바운드 구역(203) 및 드롭 구역(207) 사이에서 아이템을 운반하도록 작동한다. (예를 들면, 예측된 수요로 인해) 픽업 구역에 아이템(202A, 202B)이 필요하면, 포크리프트는 아이템(202A, 202B)을 드롭 구역(207)으로 운반할 수 있다.
드롭 구역(207)은 픽업 구역(209)으로 운반되기 전에 아이템을 저장하는 FC(200)의 영역일 수 있다. 픽업 동작에 할당된 작업자("피커(picker)")는 픽업 구역의 아이템(202A, 202B)에 접근하고, 픽업 구역에 대한 바코드를 스캔하며, 모바일 디바이스(예를 들면, 디바이스(119B))를 사용하여 아이템(202A, 202B)과 관련된 바코드를 스캔할 수 있다. 이러한 이벤트는 아이템이 FC로 이동되었음을 지정하기 위해 데이터베이스를 업데이트하는 실시간 위치 시스템을 업데이트 할 수 있다. 그 다음 피커는 (예를 들어, 카트에 놓거나 운반함으로써) 픽업 구역(209)에 아이템을 가져갈 수 있고 실시간 위치 시스템은 새로운 아이템에 대한 스토리지의 위치를 요청할 수 있다.
픽업 구역(209)은 아이템(208)이 저장 유닛(210)에 저장되는 FC(200)의 영역일 수 있다. 일부 실시예에서, 저장 유닛(210)은 물리적 선반, 책꽂이, 박스, 토트(tote), 냉장고, 냉동고, 저온 저장고 등 중 하나 이상을 포함할 수 있다. 일부 실시예에서, 픽업 구역(209)은 다수의 플로어로 편성될 수 있다. 일부 실시예에서, 작업자 또는 기계는, 예를 들면, 포크리프트, 엘리베이터, 컨베이어 벨트, 카트, 핸드트럭, 짐수레, 자동화된 로봇 또는 디바이스, 또는 수작업을 포함하는 다양한 방식으로 아이템을 픽업 구역(209)으로 운반할 수 있다. 예를 들면, 피커는 아이템(202A, 202B)을 드롭 구역(207)의 핸드트럭 또는 카트에 놓을 수 있으며, 아이템(202A, 202B)을 픽업 구역(209)으로 가져갈 수 있다.
피커는 저장 유닛(210) 상의 특정 공간과 같은 픽업 구역(209)의 특정 스팟에 아이템을 배치(또는 "적재(stow)")하라는 명령을 수신할 수 있다. 예를 들면, 피커는 모바일 디바이스(예를 들면, 디바이스(119B))를 사용하여 아이템(202A)을 스캔할 수 있다. 디바이스는, 예를 들면, 통로, 선반 및 위치를 나타내는 시스템을 사용하여, 아이템(202A)을 적재해야 하는 위치를 나타낼 수 있다. 일부 실시예에서, 아이템(202A)을 적재할 위치는, 새벽 배달과 같은 특별 배달 옵션의 가용성을 최대화하려고 시도하는 예측 알고리즘에 기초하여 결정될 수 있다. 그 다음 디바이스는 그 위치에 아이템(202A)을 적재하기 전에 피커가 그 위치에서 바코드를 스캔하도록 할 수 있다. 대안적으로, 무선 센서 또는 이미지 인식과 결합된 카메라는, 시간의 위치를 저장할 수 있다. 일부 실시예에서, 디바이스는 도 1a의 WMS(119)와 같은 컴퓨터 시스템에 아이템(202A)이 디바이스(119B)를 사용하는 사용자에 의해 그 위치에 적재되었음을 나타내는 데이터를 (예를 들면, 무선 네트워크를 통해) 전송할 수 있다.
일단 사용자가 주문을 하면, 피커는 저장 유닛(210)으로부터 하나 이상의 아이템(208)을 검색하기 위해 디바이스(119B)에 명령을 수신할 수 있다. 일부 실시예에서, 도 11과 관련하여 추가로 설명되는 바와 같이, 피커는 제품을 적재하기 위한 배치 또는 보관 가이드를 통해 명령을 수신할 수 있다. 피커는 아이템(208)을 검색하고, 아이템(208) 상의 바코드를 스캔하며, 운송 기구(214) 상에 놓을 수 있다. 일부 실시예에서, 운송 기구(214)가 슬라이드로서 표현되지만, 운송 기구는 컨베이어 벨트, 엘리베이터, 카트, 포크리프트, 핸드트럭, 짐수레, 카트 등 중 하나 이상으로서 구현될 수 있다. 그 다음 아이템(208)은 패킹 구역(211)에 도착할 수 있다.
패킹 구역(211)은 아이템이 픽업 구역(209)으로부터 수령되고 고객에게 최종 배송하기 위해 박스 또는 가방에 패킹되는 FC(200)의 영역일 수 있다. 패킹 구역(211)에서, 아이템을 수령하도록 할당된 작업자("리비닝 작업자(rebin worker)")는 픽업 구역(209)으로부터 아이템(208)을 수령하고, 그것이 어느 주문에 대응하는지를 결정할 것이다. 예를 들면, 리비닝 작업자는 아이템(208) 상의 바코드를 스캔하기 위해 컴퓨터(119C)와 같은 디바이스를 사용할 수 있다. 컴퓨터(119C)는 아이템(208)이 어느 주문과 관련이 있는지를 시각적으로 나타낼 수 있다. 이는, 예를 들면, 주문에 대응하는 월(216) 상의 공간 또는 "셀(cell)"을 포함할 수 있다. (예를 들면, 셀에 주문의 모든 아이템이 포함되어 있기 때문에) 일단 주문이 완료되면, 리비닝 작업자는 패킹 작업자(또는 "패커(packer)")에게 주문이 완료된 것을 알릴 수 있다. 패커는 셀로부터 아이템을 검색하고, 배송을 위해 이들을 박스 또는 가방에 놓을 수 있다. 그 다음 패커는, 예를 들면, 포크리프트, 카트, 짐수레, 핸드트럭, 컨베이어 벨트, 수작업 또는 다른 방법을 통해, 박스 또는 가방을 허브 구역(213)으로 보낼 수 있다.
허브 구역(213)은 패킹 구역(211)으로부터 모든 박스 또는 가방("패키지(packages)")을 수신하는 FC(200)의 영역일 수 있다. 허브 구역(213)의 작업자 및/또는 기계는 패키지(218)를 검색하고, 각 패키지가 배달 영역의 어느 부분으로 배달되도록 되어 있는지를 결정하며, 패키지를 적합한 캠프 구역(215)으로 보낼 수 있다. 예를 들면, 배달 영역이 2개의 작은 하위 영역을 갖는다면, 패키지는 2개의 캠프 구역(215) 중 하나로 보내질 것이다. 일부 실시예에서, 작업자 또는 기계는 최종 목적지를 결정하기 위해 (예를 들면, 디바이스(119A-119C) 중 하나를 사용하여) 패키지를 스캔할 수 있다. 패키지를 캠프 구역(215)으로 보내는 것은, 예를 들면, (우편 번호에 기초하여) 패키지가 향하는 지리적 영역의 부분을 결정하고, 지리적 영역의 부분과 관련된 캠프 구역(215)을 결정하는 것을 포함할 수 있다.
일부 실시예에서, 캠프 구역(215)은 루트 및/또는 서브-루트로 분류하기 위해 허브 구역(213)으로부터 패키지가 수령되는 하나 이상의 빌딩, 하나 이상의 물리적 공간, 또는 하나 이상의 영역을 포함할 수 있다. 일부 실시예에서, 캠프 구역(215)은 FC(200)로부터 물리적으로 분리되어 있는 반면, 다른 실시예에서는 캠프 구역(215)은 FC(200)의 일부를 형성할 수 있다.
캠프 구역(215)의 작업자 및/또는 기계는, 예를 들면, 목적지와 기존 루트 및/또는 서브-루트의 비교, 각각의 루트 및/또는 서브-루트에 대한 작업량의 계산, 하루 중 시간, 배송 방법, 패키지(220)를 배송하기 위한 비용, 패키지(220)의 아이템과 관련된 PDD, 배달 옵션 등에 기초하여 패키지(220)가 어느 루트 및/또는 서브-루트와 연관되어야 하는지를 결정할 수 있다. 일부 실시예에서, 작업자 또는 기계는 최종 목적지를 결정하기 위해 (예를 들면, 디바이스(119A-119C) 중 하나를 사용하여) 패키지를 스캔할 수 있다. 일단 패키지(220)가 특정 루트 및/또는 서브-루트에 할당되면, 작업자 및/또는 기계는 배송될 패키지(220)를 운반할 수 있다. 예시적인 도 2에서, 캠프 구역(215)은 트럭(222), 자동차(226), 배달원(224A, 224B)을 포함한다. 일부 실시예에서, 배달원(224A)이 트럭(222)을 운전할 수 있는데, 이 때 배달원(224A)은 FC(200)에 대한 패키지를 배달하는 풀-타임 직원이며, 트럭은 FC(200)를 소유, 임대 또는 운영하는 동일한 회사에 의해 소유, 임대, 또는 운행된다. 일부 실시예에서, 배달원(224B)이 자동차(226)를 운전할 수 있는데, 이 때 배달원(224B)은 필요에 따라(예를 들면, 계절에 따라) 배달하는 "플렉스(flex)" 또는 비상시적인 작업자이다. 자동차(226)는 배달원(224B)에 의해 소유, 임대 또는 운행될 수 있다.
일부 실시예에서, 도 2에 도시된 바와 같이, FC(200)의 섹션 중 하나 이상은 포지셔닝 시스템(217)을 포함할 수 있다. 포지셔닝 시스템(217)은 FC 내에서 제품의 위치를 결정하고 FC를 통해 그들의 움직임을 추적하는데 이용될 수 있는 복수의 센서를 포함할 수 있다. 이러한 실시예에서, 포지셔닝 시스템(217)의 센서는 FC에서 제품의 위치를 추적하고 또한 서로 다른 섹션 사이의 이동을 추정하는 두 가지 모두에 이용될 수 있다. 예를 들어, 포지셔닝 시스템(217)의 센서는 FC(200)의 서로 다른 영역들 사이에서 경과된 시간의 이력 데이터를 저장하는데 이용될 수 있다. 그런 다음 이 정보는 저장 구역과 패킹 구역 사이의 거리 또는 추정된 시간을 결정하기 위해 이용될 수 있다.
도 2에 도시된 바와 같이 포지셔닝 시스템(217)은 패킹 구역(211)의 센서(217A), 픽업 구역(209)의 센서(217B) 및 드롭 구역(205)의 센서(217C)를 포함할 수 있다. 그러나, 아이템 FC(200)의 위치를 추적 및 캡처하고 예상된 배달의 정확도를 개선하거나 배달 옵션의 가용성을 최대화 하는 것을 목표로 더 많은 센서가 FC(200)의 서로 다른 영역에 배치될 수 있다.
도 3은 개시된 실시예에 따른, 예시적인 시스템(300)의 블록도이다. 시스템(300)에서, 다중 도메인리포팅(MDR) 시스템(320)은 실시간 클라이언트 디바이스 또는 도메인의 데이터 스트림으로부터의 정보 요청을 처리하도록 구성된 서버, 컴퓨터 모듈 및/또는 데이터 처리 센터를 포함할 수 있다. 예를 들어, MDR 시스템(320)은 클라이언트 또는 도메인 데이터에 기초하여 주문 또는 티켓에 대한 정보를 수집 및/또는 제공할 수 있다. 또한, MDR 시스템(320)은 상태 요청을 해결하기 위해, 로컬 도메인(360) 및 제3자 도메인(365)과 같은, 도메인에 의해 처리되고 있는 주문 또는 티켓에 대한 정보를 추적하고 제공할 수 있다. MDR 시스템(320)은 또한 상태 정보가 있는 웹 페이지를 디스플레이 하기 위한 명령을 생성하고/하거나 시스템(300)에 의해 처리하고 있는 주문의 실시간 모니터링을 위한 서비스를 노출할 수 있다. 또한, MDR 시스템(320)은 정보의 패킷을 코드화하고, 클라이언트 디바이스에서 GUI 디스플레이를 위한 명령을 생성하고, 정보를 정렬하고 저장할 수 있다.
MDR 시스템(320)은 시스템(300)에서 통신을 분석할 수 있는 MDR 프로세서(322)를 포함할 수 있다. 또한, MDR 시스템(320)은 분산된 인-메모리 키-값 데이터베이스를 구현하는 인-메모리 데이터 구조를 저장하고 관리하는 MDR 데이터베이스(325)를 포함할 수 있다. 이러한 실시예에서, MDR 시스템(320) 및 MDR 데이터베이스(325)는, 문자열, 목록, 맵, 세트, 정렬된 세트, HyperLogLog, 비트맵, 스트림 및 공간 인덱스와 같은, 서로 다른 종류의 추상 데이터 구조를 지원할 수 있다. 더욱이, 일부 실시예에서 MDR 시스템(320)은 실시간 데이터 피드(예를 들어, 정보에 대한 실시간 탐색)를 처리하기 위한 통합된, 고 처리량, 저 지연 모듈을 제공하는 스트림 처리 소프트웨어 용 모듈을 포함할 수 있다. 이러한 실시예에서, MDR 시스템(320)은 정보 및 메시지 세트의 교환을 위해 TCP 기반 프로토콜을 이용할 수 있다.
일부 실시예에서, MDR 시스템(320)은 시스템(100)(도 1a)의 구성 요소 중 하나 이상으로 구현될 수 있다. 예를 들어, MDR 시스템(320)은 SAT 시스템(101), 외부 프론트 엔드 시스템(103), FO 시스템(113), SCM 시스템(117) 및/또는 WMS(119)(도 1a)로 구현될 수 있다. 다른 실시예에서, MDR 시스템(320)은 클라이언트 디바이스에 콘텐츠를 제공하고/하거나 클라이언트 디바이스(350)에 대한 웹 페이지를 생성하고/하거나 로컬 도메인(360)에 디스플레이 하기 위한 동작을 수행하도록 구성된 하나 이상의 독립 서버로 구현될 수 있다. MDR 시스템(320)은, MDR 프로세서(322) 및 MDR 데이터베이스(325)와 함께, 도 6과 관련하여 추가로 논의된다.
시스템(300)은, MDR 시스템(320) 외에, 온라인 리소스(340), 클라이언트 디바이스(350), 제3자 도메인(365), 로컬 도메인(360) 및 데이터베이스(380)를 포함할 수 있다. 도 3에서와 같이, 일부 실시예에서, 시스템(300)의 구성 요소는 네트워크(370)에 연결될 수 있다. 그러나, 다른 실시예에서 시스템(300)의 구성 요소는, 네트워크(370) 없이, 서로 직접 연결될 수 있다. 예를 들어, 데이터베이스(380)는 MDR 시스템(320)에 직접 연결될 수 있다.
온라인 리소스(340)는 웹 페이지 호스팅, 네트워킹, 클라우드 또는 백업 서비스의 제공자와 같은 엔티티에 의해 제공되는 하나 이상의 서버 또는 저장 서비스를 포함할 수 있다. 일부 실시예에서, 온라인 리소스(340)는 인증 서비스, DNS (Domain Name System) 또는 랜딩 페이지를 위한 웹 페이지를 저장하는 호스팅 서비스 또는 서버와 연관될 수 있다. 다른 실시예에서, 온라인 리소스(340)는 클라우드 컴퓨팅 서비스와 연관될 수 있다. 또 다른 실시예에서, 온라인 리소스(340)는, Apple Push Notification Service, Azure Mobile services 또는 Google Cloud Messaging과 같은, 메시징 서비스와 연관될 수 있다. 이러한 실시예에서, 온라인 리소스(340)는, 디지털 권리 관리를 처리하는 것과 같이, 개시된 실시예의 기능과 관련된 메시지 및 통지의 전달을 처리 할 수 있다.
클라이언트 디바이스(350)는 개시된 실시예에 따른 하나 이상의 동작을 수행하도록 구성된 하나 이상의 컴퓨팅 디바이스를 포함할 수 있다. 예를 들어, 클라이언트 디바이스(350)는 데스크톱 컴퓨터, 랩톱, 서버, 모바일 디바이스(예를 들면, 태블릿, 스마트 폰 등), 셋톱 박스, 게임 디바이스, 웨어러블 컴퓨팅 디바이스 또는 다른 임의의 컴퓨팅 디바이스를 포함할 수 있다. 일부 실시예에서, 클라이언트 디바이스(350)는 사용자 디바이스(102A/102B)(도 1a)를 포함할 수 있고 시스템(100)의 일부로서 운용될 수 있다. 그러나, 다른 실시예에서, 클라이언트 디바이스(350)는 시스템(100)으로부터 독립적일 수 있다. 클라이언트 디바이스(350)는 아래에 설명된 기능을 구현하기 위한 동작을 수행하기 위해, 클라이언트 디바이스(350) 내의 메모리와 같은, 메모리에 저장된 소프트웨어 명령을 실행하도록 구성된 하나 이상의 프로세서를 포함할 수 있다. 예를 들어, 클라이언트 디바이스(350)는 MDR 시스템(320)에 의해 제공되는 주문 또는 티켓의 상태를 포함하는 웹 페이지에 그래픽 사용자 인터페이스를 디스플레이 하도록 구성될 수 있다. 또한, 클라이언트 디바이스(350)는, 콜백 스크립트 또는 기능과 같이, MDR 시스템(320)에 의해 전송되는 명령에 따라 동작을 수행하도록 구성될 수 있다. 또한, 클라이언트 디바이스(350)는 유선 및/또는 무선 통신을 위해 구성될 수 있으며 프로세서에 의해 실행될 때 인터넷 관련 통신(예를 들면, TCP/IP) 및 콘텐츠 디스플레이 프로세스를 수행하는 소프트웨어를 포함할 수 있다. 예를 들어, 클라이언트 디바이스(350)는 제품 정보와 함께 인터페이스를 생성하고 디스플레이 하는 브라우저 소프트웨어를 실행할 수 있다. 따라서, 클라이언트 디바이스(350)는 클라이언트 디바이스(350)가 네트워크(370)를 통해 구성 요소와 통신하고 클라이언트 디바이스(350)에 포함된 디스플레이 디바이스를 통해 인터페이스에 콘텐츠를 디스플레이 하게 하는 애플리케이션을 실행할 수 있다.
일부 실시예에서, 도 4와 관련하여 추가로 설명된 바와 같이, 클라이언트 디바이스(350)는 MDR 시스템(320)과 상호 작용하도록 특별히 구성된 애플리케이션을 운용할 수 있다. 또한, 클라이언트 디바이스(350)는 하나 이상의 계정을 저장할 수 있다. 예를 들어, 클라이언트 디바이스(350)는 PDD를 수정하고/하거나 패키지를 재라우팅 하기 위해 고객 계정의 권한에 대한 정보를 저장할 수 있다.
개시된 실시예는 클라이언트 디바이스(350)의 임의의 특정 구성으로 제한되지 않는다. 예를 들어, 클라이언트 디바이스(350)는 MDR 시스템(320) 및/또는 온라인 리소스(340)에 의해 제공되는 기능을 제공하는 동작을 수행하기 위해 모바일 애플리케이션을 저장하고 실행하는 모바일 디바이스 일 수 있다. 특정 실시예에서, 클라이언트 디바이스(350)는 GPS 위치와 같은 위치 서비스에 관한 소프트웨어 명령을 실행하도록 구성될 수 있다. 예를 들어, 클라이언트 디바이스(350)는 지리적 위치를 결정하고 위치 데이터 및 위치 데이터에 대응하는 타임 스탬프 데이터를 제공하도록 구성될 수 있다. 클라이언트 디바이스(350)는 도 4와 관련하여 추가로 설명된다.
데이터베이스(380)는 시스템(300)에서 주문 또는 티켓을 추적하기 위해 MDR 시스템(320) 데이터를 제공하는 것에 따른 동작을 수행하기 위해 적절한 소프트웨어로 구성된 하나 이상의 컴퓨팅 디바이스를 포함할 수 있다. 데이터베이스(380)는, 예를 들어, OracleTM 데이터베이스, SybaseTM 데이터베이스 또는 다른 관계형 데이터베이스, 또는, Hadoop 시퀀스 파일, HBase 또는 Cassandra와 같은, 비-관계형 데이터베이스를 포함할 수 있다. 데이터베이스(380)는 데이터베이스(들)의 메모리 장치에 저장된 데이터에 대한 요청을 수신 및 처리하고 데이터베이스(들)로부터 데이터를 제공하도록 구성된 컴퓨팅 구성 요소(예를 들어, 데이터베이스 관리 시스템, 데이터베이스 서버 등)를 포함 할 수 있다.
데이터베이스(380)는 별도로 도시되지만, 일부 실시예에서 데이터베이스(380)는 MDR 시스템(320) 또는 온라인 리소스(340)에 포함되거나 달리 관련될 수 있다.
데이터베이스(380)는 가용 배달 옵션의 결정을 용이하게 하기 위해 사용자 계정 또는 제품과 연관된 데이터를 수집 및/또는 유지하도록 구성될 수 있다. 예를 들어, 데이터베이스(380)는 시스템(300)의 사용자를 위한 사용자 프로파일에 관한 정보를 저장할 수 있다. 또한, 데이터베이스(380)는, 주소에 대해 가용 배달 옵션을 포함하여, 주소에 관한 정보를 저장할 수 있다. 데이터베이스(380)는, 예를 들어, 온라인 리소스(340) 또는 제3자 도메인(365)을 포함하는, 다양한 소스로부터 데이터를 수집할 수 있다. 또한, 데이터베이스(380)는 클라이언트 디바이스(350) 운영 체제에 대한 정보를 포함할 수 있다. 데이터베이스(380)는 도 5와 관련하여 아래에서 추가로 설명된다.
로컬 도메인(360)은 시스템(100)의 하나 이상의 요소를 포함할 수 있다. 예를 들어, 로컬 도메인(360)은 SAT 시스템(101), 판매자 포털(109), FO 시스템(113) 및/또는 SCM 시스템(117)을 포함할 수 있다. 대안으로, 또는 추가적으로, 로컬 도메인(360)은 시스템(300)의 로컬 네트워크에 대한 서버 및/또는 액세스 포인트를 포함할 수 있다. 예를 들어, 로컬 도메인(360)은 주문 처리 도메인, 구매 도메인, 재고 도메인, 보안 도메인 및 클라이언트 페이싱(facing) 도메인을 포함할 수 있다. 이러한 도메인은 클라이언트 주문의 이행을 지원하기 위한 로컬 네트워크 및 네트워크 리소스를 포함할 수 있다. 더욱이, 일부 실시예에서 로컬 도메인(360)은 다중 도메인 네트워크의 매니저 또는 관리자가 시스템(300) 전체에서 처리되고 있는 주문 또는 티켓의 상태에 대해 MDR 시스템(320)을 질의할 수 있게 하는 모니터링 엔진 도메인 또는 관리자 도메인을 포함할 수 있다. 예를 들어, 로컬 도메인(360)은 예측되는 또는 실제 지연이 있는 주문 또는 티켓에 관한 상태 업데이트를 주기적으로 요청하는 모니터링 엔진을 포함할 수 있다. 이러한 실시예에서, 로컬 도메인(360)은, 도메인 관리자와 같은, 관리자 도메인을 포함할 수 있다.
일부 실시예에서, 제3자 도메인(365)은 시스템(100)의 하나 이상의 요소를 포함할 수 있다. 예를 들어, 제3자 도메인(365)은 3PL 시스템(121A-121C)(도 1)을 포함할 수 있다. 추가적으로, 또는 대안적으로, 제3자 도메인(365)은, 서비스의 제공자 또는 풀필먼트 센터와 같은, MDR 시스템(320)과 관련된 엔티티에 의해 제공되는 하나 이상의 서버 또는 저장 서비스를 포함할 수 있다. 제3자 도메인(365)은 또한 네트워크(370)를 통해 시스템(300)에 연결될 수 있지만, 다른 실시예에서 제3자 도메인(365)은 시스템(300)의 일부 요소와의 직접 연결을 포함할 수 있다. 예를 들어, 지연 또는 네트워크 혼잡을 최소화하기 위해 제3자 도메인(365)은 MDR 시스템(320)과 함께 사설 네트워크에 연결될 수 있다. 또한, 제3자 도메인(365)은 MDR 시스템(320) 또는 시스템(300)의 다른 요소로부터 정보를 제공 및/또는 요청하도록 구성될 수 있다. 일부 실시예에서, 제3자 도메인(365)은 또한 네트워크(370)에 연결될 수 있지만, 이들은 MDR 시스템(320)의 클라이언트가 아닐 수 있다. 대신, 제3자 도메인(365)은 MDR 시스템(320)의 사용자 또는 클라이언트의 정보를 포함하는 시스템을 포함할 수 있다. 예를 들어, 제3자 도메인(365)은, 제품 배달이 제3자 계약자를 포함할 때 MDR 시스템(320)에 의해 이용될 수 있는, 배달 계약자의 서버를 포함 할 수 있다.
네트워크(370)는 시스템(300)의 구성 요소들 간의 통신을 제공하도록 구성된 임의의 유형의 네트워크 일 수 있다. 예를 들어, 네트워크(370)는 통신을 제공하고, 정보를 교환하며 및/또는 인터넷, 근거리 통신망(Local Area Network), 근거리 통신(NFC), 또는 시스템(300)의 구성 요소들 사이에서 정보의 송수신을 가능하게 하는 다른 적합한 연결(들)과 같은, 정보의 교환을 용이하게 하는 임의의 유형의 네트워크(인프라 포함)일 수 있다. 다른 실시예에서, 하나 이상의 시스템(300)의 구성 요소는 전용 통신 링크(들)를 통해 직접 통신할 수 있다. 또 다른 실시예에서, 네트워크(370)는 예를 들어 네트워크나 네트워크들을 구성하는 다중 네트워크를 포함할 수 있다.
시스템(300)의 기능적 빌딩 블록의 구성 및 경계는 설명의 편의를 위해 본 명세서에 정의된 것으로 이해되어야 한다. 특정 기능 및 그 관계가 적절하게 수행되는 한 대안적인 경계가 정의될 수 있다. 대안(본 명세서에 기재된 것들의 균등물, 확장물, 변형물, 변동물(deviations) 등을 포함)은 명백할 것이다. 그러한 대안들은 개시된 실시예의 범위 내에 속한다.
이제 도 4를 참조하면, 개시된 실시예에 따른, 예시적인 클라이언트 디바이스(350)(도 3)의 블록도가 도시된다. 일부 실시예에서, 클라이언트 디바이스(350)는 사용자 디바이스(102)(도 1a)를 구현할 수 있다.
하나의 실시예에서, 클라이언트 디바이스(350)는 하나 이상의 프로세서(402), 하나 이상의 입출력(I/O) 디바이스(404) 및 하나 이상의 메모리(410)를 포함할 수 있다. 일부 실시예에서, 클라이언트 디바이스(350)는 스마트폰이나 태블릿, 범용 컴퓨터 또는 이러한 구성 요소의 임의의 조합과 같은 모바일 컴퓨팅 디바이스의 형태를 취할 수 있다. 대안적으로, 클라이언트 디바이스(350)(또는 클라이언트 디바이스(350)를 포함하는 시스템)은 개시된 실시예에 따른 하나 이상의 동작을 수행하는 소프트웨어 명령의 저장, 실행 및/또는 구현에 기초하여 특정 장치, 임베디드 시스템, 전용 회로로 구성될 수 있다. 일부 실시예에 따르면, 클라이언트 디바이스(350)는 개시된 실시예에 따른 웹 사이트에 액세스하는 웹 브라우저나 유사한 컴퓨팅 디바이스를 포함할 수 있다.
프로세서(402)는, lntelTM, NVIDIATM에 의해 제조된 모바일 디바이스 마이크로프로세서 또는 다른 제조업체의 다양한 프로세서와 같은, 하나 이상의 알려진 처리 디바이스를 포함할 수 있다. 개시된 실시예는 클라이언트 디바이스(350)에 구성된 어떤 특정 유형의 프로세서에 한정되지 않는다.
메모리(410)는 개시된 실시예와 관련된 기능을 수행하기 위해 프로세서(402)에 의해 사용되는 명령을 저장하도록 구성된 하나 이상의 스토리지 디바이스를 포함할 수 있다. 예를 들어, 메모리(410)는, 프로세서(402)에 의해 실행될 때 동작을 수행할 수 있는 프로그램(412)과 같은, 하나 이상의 소프트웨어 명령으로 구성될 수 있다. 개시된 실시예는 전용 작업을 수행하도록 구성된 별도의 프로그램이나 컴퓨터에 한정되지 않는다. 예를 들어, 메모리(410)는 클라이언트 디바이스(350)의 기능을 수행하는 단일 프로그램(412)을 포함할 수 있고, 또는 프로그램(412)은 다수의 프로그램을 포함할 수 있다. 메모리(410)는 또한 시스템(300)의 다른 요소와 상호 작용하기 위해 통신하거나 동작을 실행하도록 클라이언트 디바이스(350)를 구성할 수 있는 클라이언트 애플리케이션(414)을 포함할 수 있다. 예를 들어, 클라이언트 애플리케이션(414)은 MDR 시스템(320)과 통신하고/하거나 주문 정보 요청을 생성하기 위한 명령을 지정할 수 있다. 더욱이, 클라이언트 애플리케이션(414)은 사용자가 MDR 데이터베이스(325)와 상호 작용하여 머신-러닝 모델을 트레이닝 하기 위한 정보를 읽고, 쓰고 및/또는 수집하는 것과 같은 동작을 수행할 수 있게 한다. 메모리(410)는 또한 주문 또는 제품의 상태에 관한 정보를 갖는 상태 테이블을 생성하고 유지하기 위해 MDR 시스템(320)에 의해 이용될 수 있는 데이터(416)를 저장할 수 있다.
특정 실시예에서, 메모리(410)는 MDR 시스템(320)에 액세스하거나 요청을 전송하기 위한 명령을 저장할 수 있다. 예를 들어, 메모리(410)는 TCP/IP를 통해 MDR 시스템(320)과 통신하는 애플리케이션을 포함할 수 있다. 대안적으로, 또는 추가적으로, 메모리(410)는 애플리케이션 프로그래밍 인터페이스(API) 방법을 통해 MDR 시스템(320)과 통신하기 위한 정보를 포함할 수 있다. 예를 들어, 일부 실시예에서 MDR 시스템(320)은 (1) 모니터링 이벤트 엔티티 생성, (2) 모니터 엔티티 업데이트 및 (3) 누락된 상태 이벤트 리포팅과 같은 서비스를 위해 REST API를 노출할 수 있다. 이러한 실시예에서, 메모리(410)는 노출된 API 서비스를 이용하여 MDR 시스템(320)에 정보를 요청하거나 MDR 시스템(320)으로부터의 정보를 전송하기 위해 GET, PUT, DELETE 또는 POST 명령을 발행하기 위한 명령을 저장할 수 있다.
더욱이, 다른 소프트웨어 구성 요소는 MDR 시스템(320)으로부터 정보를 요청하거나 클라이언트 디바이스(350)의 위치를 결정하도록 구성 될 수 있다. 예를 들어, 프로그램(412)의 소프트웨어 명령은, 프로세서(들)(402)에 의해 실행될 때, 정보를 처리하여 웹 페이지에 아이템의 목록을 디스플레이 할 수 있다. 소프트웨어 명령은 또한 클라이언트 디바이스(350)에 디스플레이 되고 있는 웹 페이지를 수정하기 위한 스크립트를 구현할 수 있다.
I/O 디바이스(404)는 클라이언트 디바이스(350)에 의해 데이터를 수신 및/또는 전송되도록 구성되고 클라이언트 디바이스(350)가, 시스템(300)의 다른 구성 요소와 같은, 다른 기계 및 디바이스와 통신할 수 있도록 구성된 하나 이상의 디바이스를 포함할 수 있다. 예를 들어, I/O 디바이스(404)는 소포의 배달을 확인하거나 사용자에게 정보를 제공하기 위한 화면을 포함 할 수 있다. I/O 디바이스(404)는 또한 NFC 통신을 위한 구성 요소를 포함할 수 있다. I/O 디바이스(404)는 또한 사용자가 터치 감지 영역, 버튼 또는 마이크와 같이 클라이언트 디바이스(350)와 상호작용할 수 있게 하는 하나 이상의 디지털 및/또는 아날로그 디바이스를 포함할 수 있다. I/O 디바이스(404)는 또한 클라이언트 디바이스(350)의 방향과 관성을 감지하기 위한 하나 이상의 가속도계를 포함할 수 있다. I/O 디바이스(404)는 또한 MDR 시스템(320)과의 상호 작용을 위해 당업계에 알려진 다른 구성요소들을 포함할 수 있다.
일부 실시예에서, 클라이언트 디바이스(350)는 또한 이미지를 캡처하는 카메라(420)를 포함할 수 있으며, 제품의 식별에 이용될 수 있다. 이러한 식별은 디스플레이를 위한 콘텐츠 정보에 대한 요청을 트리거할 수 있다. 추가적으로, 또는 대안적으로, 클라이언트 디바이스(350)는 사용자가 그들의 계정에 엑세스 하기 위해 클라이언트 디바이스(350)의 잠금을 해제하고, 정보에 대한 요청을 전송하고, 아이템을 구매할 수 있게 하는 지문 센서(430)를 포함할 수 있다. 카메라(420)와 지문 센서(430)는 모두 프로세서(402)에 의해 동작될 수 있으며 사용자가 지문이나 카메라 정보에 외부적으로 접근하는 것을 불가능하게 만들기 위해 암호화 보안을 사용할 수 있다.
클라이언트 디바이스(350)의 구성요소는, 당업자에게 명백한 바와 같이, 하드웨어, 소프트웨어 또는 하드웨어와 소프트웨어의 조합으로 구현될 수 있다.
이제 도 5를 참조하면, 개시된 실시예에 따른, 예시적인 하나의 데이터베이스(380)(도 3)의 블록도가 도시된다. 일부 실시예에서, 데이터베이스(380)는 시스템(100)의 요소에 포함될 수 있다. 예를 들어, 데이터베이스(380)는 외부 프론트 엔드 시스템(103) 또는 WMS(119)(도 1a)의 일부일 수 있다.
데이터베이스(380)는 통신 디바이스(502), 하나 이상의 데이터베이스 프로세서(504), 및 하나 이상의 데이터베이스 프로그램(512) 및 데이터(514)를 포함하는 데이터베이스 메모리(510)를 포함할 수 있다. 데이터베이스(380)는 HBase, MongoDBTM 또는 CassandraTM와 같은 NoSQL 데이터베이스를 포함할 수 있다. 대안적으로, 데이터베이스(380)는 Oracle, MySQL 및 Microsoft SQL Server와 같은 관계형 데이터베이스를 포함할 수 있다.
일부 실시예에서, 데이터베이스(380)는 서버, 범용 컴퓨터, 메인 프레임 컴퓨터, 또는 이들 구성 요소의 임의의 조합일 수 있다. 일부 실시예에서, 데이터베이스(380)는, MDR 시스템(320)과 같은, 시스템(300)의 다른 요소 내에 포함된다. 개시된 실시예들에 따른 다른 구현이 가능하다.
일부 실시예에서, 데이터베이스(380)는 비 관계형 및 임베디드 데이터베이스 모두를 포함할 수 있다. 예를 들어, 데이터베이스(380)는, Hbase와 같은, 비 관계형 데이터베이스 및, RocksDB(예를 들어, 키-값 저장 데이터베이스)와 같은, 임베디드 데이터베이스를 포함할 수 있다.
통신 디바이스(502)는, 온라인 리소스(340), MDR 시스템(320), 또는 SCM 시스템 (117)과 같은, 시스템(300) 또는 시스템(100)의 하나 이상의 구성 요소와 통신하도록 구성될 수 있다. 통신 디바이스(502)는 MDR 시스템(320) 주문 정보 및 사용자 선호도 또는 특권을 제공하도록 구성될 수 있다.
데이터베이스(380)의 구성 요소는 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합으로 구현될 수 있다. 예를 들어, 데이터베이스(380)의 하나 이상의 구성 요소가 컴퓨터 처리 명령 모듈로서 구현될 수 있지만, 데이터베이스(380)의 기능의 전부 또는 일부는 전용 전자 하드웨어 대신 구현될 수 있다.
데이터베이스 메모리(510)는, 로컬 도메인(360) 및 제3자 도메인(365)으로부터 상태 메시지를 수신 및 처리하고/하거나 클라이언트 디바이스(350)로부터의 정보 요청에 응답하기 위한 명령을 포함 할 수 있는, 프로그램(512)을 포함할 수 있다. 또한, 데이터베이스 메모리(510)는 시스템(300)의 요소들 간의 통신을 위한 명령을 포함할 수 있다. 예를 들어, 데이터베이스 메모리(510)는 클라이언트 디바이스(350)와 MDR 시스템(320) 간의 통신을 위한 명령을 포함할 수 있다. 또한, 프로그램(512)은 정보가 MDR 시스템(320)에 의해 처리될 때 실시간으로 정보를 저장하기 위한 명령을 포함할 수 있다. 이러한 실시예에서, 도 11과 관련하여 추가로 개시된 바와 같이, 데이터베이스(380)는 ID 필드, 예상 완료 필드 및 상태 필드를 포함하는 상태 테이블을 저장할 수 있다.
데이터(514)는 또한 주문 상태, 예상 배달 및 목표 PDD와 연관된 데이터 일 수 있다. 데이터(514)는, 예를 들어, 시스템에서 이전에 보류중인 주문, 선택된 풀필먼트 센터 또는 재고 상태와 관련된 정보를 포함할 수 있다. 일부 실시예에서, 데이터(514)는 또한 상태 테이블 및 데이터베이스 엔트리 레코드 일 수 있다.
도 6은 개시된 실시예에 따른, 예시적인 다중 도메인 리포팅(MDR) 시스템(320)(도 3)의 블록도이다. MDR 시스템(320)은 통신 디바이스(324), MDR 데이터베이스(325) 및 하나 이상의 MDR 프로세서(322)를 포함할 수 있다. MDR 데이터베이스(325)는 MDR 프로그램(652), MDR 캐시 데이터(654) 및 MDR 상태 테이블(656)을 포함할 수 있다. MDR 프로세서(322)는 자동화된 디스커버리 모듈(642), PDD 계산기(644), 머신-러인(ML) 트레이너(646) 및 리포트(report) 생성기(648)를 포함할 수 있다.
통신 디바이스(324)는 인터넷을 통해 통신하기 위한 네트워크 제어기 및/또는 무선 어댑터를 포함할 수 있다. 통신 디바이스(324)는, 직접적으로, 또는 네트워크(170)를 통해, 설명된 데이터베이스(380)(도 3)와 같은, 하나 이상의 데이터베이스와 통신하도록 구성될 수 있다. 더욱이, 일부 실시예에서 통신 디바이스(324)는 REST API 호출 및/또는 대기열 기반 입력에 응답하도록 구성될 수 있다. 예를 들어, 통신 디바이스(310)는 REST API 방법을 통해 로컬 도메인(360) 및 제3자 도메인(365)에서 요청하는 MDR 시스템(320)의 리소스를 노출할 수 있다.
MDR 데이터베이스(325)는 개시된 실시예와 관련된 기능을 수행하기 위해 MDR 프로세서(322)에 의해 이용되는 명령을 저장하도록 구성된 하나 이상의 저장 디바이스를 포함한다. 예를 들어, MDR 데이터베이스(325)는 MDR 프로세서(322)에 의해 실행될 때 동작을 수행할 수 있는 소프트웨어 명령을 저장할 수 있다. 개시된 실시예는 전용 작업을 수행하도록 구성된 별도의 프로그램 또는 컴퓨터로 제한되지 않는다. 더욱이, MDR 데이터베이스(325)는 시스템(300)에 의해 처리하고 있는 주문 및/또는 티켓의 상태를 중앙 집중식으로 모니터링 할 수 있게 하는 데이터 구조를 저장할 수 있다. 예를 들어, MDR 데이터베이스(325)는 주문 상태를 자세히 설명하는 주문 엔트리(모니터링 엔티티로도 알려짐)를 저장하는 MDR 상태 테이블(656)을 저장할 수 있다. MDR 상태 테이블(656)은 주문 엔트리에 대한 고유 ID(아이템, 벤더 및 고객 정보에 기초하여 코드화 될 수 있음) 및 주문 또는 티켓의 상태("Missed PDD", "Sent to Warehouse" 등을 포함할 수 있음)를 포함할 수 있다. 도 11과 관련하여 추가로 설명된 바와 같이, MDR 상태 테이블(656)은 주문 ID, 엔티티 유형, 현재 상태, 예상 상태 및 균일 상태에 대한 필드를 포함할 수 있다. 일부 실시예에서, MDR 상태 테이블(656)은 질의 또는 REST API 호출을 통해 액세스 가능하도록 구성될 수 있다.
더욱이, MDR 데이터베이스(325)는 MDR 캐시 데이터(654)를 추가로 포함할 수 있다. MDR 캐시 데이터(654)는 MDR 상태 테이블(656)의 특정 엔트리의 사본 및/또는 MDR 프로세서(322)에 의해 처리되고 있는 요청을 포함할 수 있다. MDR 캐시 데이터(654)는 또한 모니터링 엔진에 대해 생성된 처리된 리포트의 사본을 캐시하고 모니터링 엔진이 요청할 때 해당 사본을 전송할 수 있다. 이러한 실시예에서, MDR 캐시 데이터(654)는 리포트가 크거나 자주 액세스되는 경우 상태 테이블(656)로부터 리포트를 검색하는 데 필요한 시간을 단축할 수 있다.
특정 실시예에서, MDR 데이터베이스(325), 특히 MDR 프로그램(652)은 상태 변수를 생성하고, 그들의 PDD를 계산하고, 및/또는 경보가 관리자 도메인으로 전송되어야 하는 시기를 결정하기 위한 프로세스를 수행하기 위한 명령을 저장할 수 있다. 다른 명령도 가능하다. 일반적으로, 명령은 개시된 실시예에 따른 프로세스를 수행하기 위해 MDR 프로세서(322)에 의해 실행될 수 있다.
MDR 프로세서(322)는 마이크로 프로세서, CPU 및/또는 멀티 코어 프로세서와 같은 (이에 한정되지 않음) 하나 이상의 알려진 처리 디바이스를 포함할 수 있다. 다른 실시예에서, MDR 프로세서(322)는 본 개시에 따른 기능을 수행하도록 결합되고 구성된 복수의 디바이스 일 수 있다. 일부 실시예에서, MDR 프로세서(322)는 MDR 프로세서(322)의 각 구성 요소와 연관된 기능을 수행하기 위해 소프트웨어를 실행할 수 있다. 다른 실시예에서, MDR 프로세서(322)의 각 구성 요소는 독립적인 디바이스 일 수 있다.
자동화된 디스커버리 모듈(642)은 새로운 디바이스 및/또는 도메인을 식별하기 위해 네트워크를 크롤하고 이들을 네트워크에 연결하고 자동화된 동작을 위해 디바이스 또는 도메인을 프로그래밍하는 자동화된 디스커버리 동작을 수행하도록 구성될 수 있다. 자동화된 디스커버리 모듈(642)은 특정 도메인 및 디바이스가 동일한 네트워크상의 다른 디바이스 또는 MDR 프로세서(322)와의 인식 및 통신에 필요한 단계를 자동화하도록 허용한다. 일부 실시예에서, 자동화된 디스커버리 모듈(642)은 도메인 또는 디바이스를 자동으로 인식하고 통신 방법을 식별하며, 업데이트 메시지 전송과 같은, 특정 작업을 구성하도록 구성될 수 있다. 예를 들어, 자동화된 디스커버리 모듈(642)은 새로운 도메인이 MDR 상태 테이블(656)을 채우는 통신을 전송하기 위해 MDR 시스템(320)과 상호 작용하고 통신하는데 필요한 단계들을 자동화 할 수 있다. 이러한 실시예에서, 자동화된 디스커버리 모듈(642)은 도메인의 디바이스에 주소를 할당하고 시스템(300)의 다른 디바이스에 그들의 식별 및 특성을 알리기 위해 그것을 브로드캐스트 할 수 있다.
더욱이, 자동화된 디스커버리 모듈(642)은 API 호출과 같은 통신을 MDR 시스템(320)과 같은 중앙집중식 리포팅 시스템에 자동으로 발행하도록 도메인 디바이스 프로그램을 프로그래밍 할 수 있다. 예를 들어, 자동화된 디스커버리 모듈(642)은 도메인(또는 도메인의 요소)에 주소를 할당하는 동작을 자동화 할 수 있고, 네트워크 상호 작용에 대한 이름을 할당하고, 이벤트의 정점 또는 시작에 의해 트리거 되는 API 통신을 프로그래밍 할 수 있다. 이러한 실시예에서, 자동화된 디스커버리 모듈(642)은 API 호출 또는 특정 메시지를 생성하도록 로컬 도메인(360) 또는 제3자 도메인(365)의 디바이스를 구성할 수 있다.
PDD 계산기(644)는 MDR 상태 테이블(656)의 엔트리를 채우기 위해 처리되고 있는 주문 또는 티켓에 대한 약속된 배달 날짜(PDD)를 결정하도록 구성될 수 있다. 예를 들어, 일단 주문이 클라이언트 디바이스(350) 중 하나로부터 수신되면, PDD 계산기(644)는 풀필먼트 센터 또는 제3자를 식별하고 할당할 수 있다. 할당에 기초하여, 그런 다음 PDD 계산기(644)는 MDR 상태 테이블(656)의 필드에 포함될 수 있는 PDD 또는 예상 배달을 추정 할 수 있다. 주문 이행이 서로 다른 도메인에서 중단된 워크 플로우를 통해 처리되는 동안, MDR 프로세서(322)는 현재 시간을 예상 PDD(PDD 계산기(644)에 의해 생성됨)와 비교하여 시스템이 경보를 생성해야 하는지 또는 특정 API 서비스를 지연의 정보 관리자 도메인에 노출해야 하는지 여부를 결정할 수 있다. 일부 실시예에서, 도 15와 관련하여 추가로 논의된 바와 같이, PDD 계산기(644)는 일련의 규칙을 이용하여 주문 또는 티켓을 특정 풀필먼트 센터에 할당 한 다음 예상된 PDD를 결정하고 주문 상태를 모니터링 할 수 있다.
일부 실시예에서, PDD 계산기(644)는 MDR 시스템(320) 외부에 있을 수 있고/있거나 시스템(100)의 하나 이상의 요소에 의해 구현될 수 있다. 예를 들어, 일부 실시예에서 PDD 계산기(644)는 FO 시스템(113) 또는 SAR 시스템(101)(도 1)으로 구현될 수 있으며 PDD 또는 예상된 배달 정보를 MDR 시스템(320)으로 전송할 수 있다.
ML 트레이너(646)는 주문 상태를 예측하고/하거나 경보를 생성하는 머신-러닝(ML) 모델을 생성하기 위해 MDR 데이터베이스(325)의 데이터를 이용하도록 구성될 수 있다. MDR 시스템(320)을 구현하는 한 가지 이점은 다중 도메인 네트워크의 균일하고 적절하게 라벨링 된 데이터를 수집하는 능력이다. 표준 다중 도메인 네트워크에서는 데이터가 분리되어 정규화하기 어려울 수 있지만, 중앙 집중식 상태 모니터링을 위한 개시된 시스템 및 방법은 네트워크로부터 데이터를 수집하고 큐레이션 할 수 있게 한다. 이러한 데이터는 멀티 도메인 네트워크를 관리하기 위한 예측 모델을 생성하기 위해 ML 트레이너(646)에 의해 활용될 수 있다. 예를 들어, ML 트레이너(646)는 PDD를 누락하거나 지연 될 주문을 예측하는 ML 모델을 트레이닝 하기 위해 MDR 데이터베이스(325)의 데이터를 이용할 수 있다. 이러한 실시예에서, ML 트레이너(646)는 하나 이상의 ML 모델을 트레이닝, 구현, 저장, 수신, 검색 및/또는 전송하기 위한 프로그램(예를 들어, 스크립트, 기능, 알고리즘)을 포함할 수 있다. ML 모델은 신경망 모델, 주의 네트워크 모델, 생성 적대 모델(GAN), 순환 신경망(RNN) 모델, 딥 러닝 모델(예를 들면, 롱 숏-텀 메모리(LSTM) 모델), 랜덤 포레스트 모델, 컨볼루션 신경망(CNN) 모델, RNN-CNN 모델, LSTM-CNN 모델, 시간-CNN 모델, 지원 벡터 머신(SVM) 모델, 노이즈가 있는 애플리케이션의 밀도 기반 공간 클러스터링(DBSCAN) 모델, k-평균 클러스터링 모델, 분포 기반 클러스터링 모델, k- 메도이드(medoids) 모델, 자연어 모델 및/또는 다른 머신-러닝 모델을 포함할 수 있다. 또한, 모델은 앙상블 모델(즉, 복수의 모델들을 포함하는 모델)을 포함할 수 있다.
일부 실시예에서, ML 트레이너(646)는 트레이닝 기준이 충족될 때 트레이닝을 종료하도록 구성될 수 있다. 트레이닝 기준은 여러 시대(epochs), 트레이닝 시간, 성능 메트릭(예를 들어, 테스트 데이터를 재생하는데 있어서의 정확도의 추정치) 등을 포함할 수 있다. ML 트레이너(646)는 트레이닝 동안 모델 파라미터를 조정하도록 구성될 수 있다. 모델 파라미터는 가중치, 계수, 오프셋 등을 포함할 수 있다. 트레이닝은 지도되거나 비지도 될 수 있다.
ML 트레이너(646)는 개시된 실시예에 따른, 최적화 기술을 이용하여 모델 파라미터 및/또는 하이퍼 파라미터(즉, 하이퍼 파라미터 튜닝)를 최적화함으로써 ML 모델을 트레이닝 하도록 구성될 수 있다. 하이퍼 파라미터는, 모델의 트레이닝이 발생하는 방식에 영향을 줄 수 있는, 트레이닝 하이퍼 파라미터, 또는 모델의 구조에 영향을 줄 수 있는, 아키텍처 하이퍼 파라미터를 포함할 수 있다. 최적화 기술은 그리드 검색, 랜덤 검색, 가우스(Gaussian) 프로세스, 베이지안(Bayesian) 프로세스, CMA-ES(Covariance Matrix Adaptation Evolution Strategy), 파생어-기반 검색, 확률적 힐-클라임(stochastic hill-climb), 주위 검색, 적응형 랜덤 검색 등을 포함할 수 있다. ML 트레이너(646)는 알려진 최적화 기술을 이용하여 통계 모델을 최적화하도록 구성될 수 있다.
리포트 생성기(648)는 MDR 상태 테이블(656)로부터의 데이터를 이용하여 리포트를 생성하기 위한 하드웨어 또는 소프트웨어를 포함할 수 있다. 예를 들어, 로컬 도메인(360)(도 3)으로부터의 특정 API 호출에 응답하여, 리포트 생성기(648)는 특정 상태와 관련된 MDR 상태 테이블(656)의 엔트리를 식별하고 관리자 도메인에 브로드캐스트 될 수 있는 리포트를 생성하도록 구성될 수 있다. 예를 들어, 통신 디바이스(324)를 통해 MDR 시스템(320)은 로컬 도메인(360)의 모니터링 엔진으로부터 API 호출을 수신하여 누락된 PDD를 갖는 주문의 리포트를 생성할 수 있다. 이러한 시나리오에서, 리포트 생성기(648)는 누락된 PDD 상태를 갖는 MDR 상태 테이블(656)의 엔트리를 식별하고 누락된 PDD를 갖는 주문을 상세히 설명하는 리포트를 생성할 수 있다. 도 17과 관련하여 추가로 논의되는 바와 같이, 일부 실시예에서 리포트는 모니터링 엔진에 의해 요청된 카테고리 상태와 일치하는 주문 또는 티켓을 포함하는 이메일 또는 텍스트 메시지 일 수 있다.
도 7은 개시된 실시예에 따른, MDR 시스템(320)을 포함하는 다중 도메인 네트워크(700)의 블록도이다. MDR 시스템(320)에 추가하여, 네트워크(700)는 주문 도메인(363), 재고 도메인(362) 및 구매 도메인(361)을 포함한다. 도메인(361-363) 각각은 로컬 도메인(360)(도 3)의 일부일 수 있고 주문 처리 과정에서 특정 작업을 수행하기 위한 전용 시스템을 포함할 수 있다. 예를 들어, 주문 도메인(363)은 클라이언트 디바이스(350)(도 3)로부터 주문을 수신하고 처리할 수 있다. 재고 도메인(362)은 외부 프론트 엔드 시스템(103)(도 1a)에 대한 재고 가용성을 유지하고 풀필먼트 센터를 할당할 수 있다. 그리고 구매 도메인(361)은 지불을 처리하고 주문과 연관된 거래를 결제할 수 있다. 이들은 단지 예시적인 로컬 도메인(360)이고 대안적으로 또는 추가적인 도메인은 네트워크(700)의 일부일 수 있다. 예를 들어, 네트워크(700)의 도메인은 보안 도메인, 광고 도메인 및/또는 고객 도메인을 포함할 수 있다.
도 6과 관련하여 이전에 논의된 바와 같이, MDR 시스템(320)은 MDR 데이터베이스(325) 및 네트워크(700)의 도메인과 통신할 수 있다. 도 7에 도시된 바와 같이, MDR 시스템(320)은 주문 도메인(363), 재고 도메인(362) 및 구매 도메인(361) 각각과 직접 연결되어, 중단된 워크 플로우 동안 주문 또는 티켓의 상태를 모니터링 하는 중앙 집중식 모니터링 시스템을 생성할 수 있다. 예를 들어, REST API 방법 및 자동화된 호출을 이용하여 MDR 시스템(320)은 네트워크(700)에서 주문 또는 티켓을 모니터링 할 수 있다. 이러한 실시예에서, 주문 도메인(363)은 고객 장치로부터 수신된 새로운 주문에 대한 모니터 이벤트 엔티티를 생성하기 위한 API 호출 또는 질의 요청을 생성하도록 구성될 수 있다. 일부 실시예에서, 이 제1 API 호출 또는 요청은 아이템 유형, 벤더 및 할당된 FC에 기초하여 인코딩 될 수 있는 주문 ID를 포함할 수 있다. 추가적으로, 재고 도메인(362)은 MDR 시스템(320)과 업데이트를 통신하도록 구성될 수 있다. 예를 들어, 재고 도메인(362)은 주문 도메인(363)에 의해 생성된 모니터 엔티티 업데이트를 요청하거나 메시지를 생성하도록 구성될 수 있다. 이 제2 업데이트 요청은 창고로부터 배송되고 있는 주문에 의해 트리거 될 수 있다. 더욱이, 구매 도메인(361)은 주문이 배송될 때 송장을 발행하기 위해 주문의 상태를 확인하기 위한 요청을 생성할 수 있다. 이러한 방식으로, MDR 시스템(320)은 통신을 중앙 집중화하고 도메인 각각이 네트워크 혼잡을 감소시키는 간단한 요청으로 주문 상태를 결정할 수 있게 한다. 이러한 실시예는 상태를 식별하기 위해 프로세스 전반에 걸쳐 전체 컨텍스트를 전달할 필요성을 제거함으로써 다중 도메인 관리의 기술 분야를 개선한다. 대신에, 네트워크(700)의 개시된 구성은 최소한의 필요한 데이터로 단일 소스에서 연결 해제된 워크 플로우의 수렴을 허용한다.
도 7에 도시된 바와 같이, 일부 실시예에서 네트워크(700)는 또한 관리자 도메인(364)을 포함할 수 있다. 관리자 도메인(364)은 네트워크(700)의 다른 도메인에 대한 특정 권한을 갖는 시스템과 연관될 수 있다. 예를 들어, 관리자 도메인(364)의 시스템은 주문의 가격을 재라우팅, 취소 또는 업데이트 하기 위한 능력을 가질 수 있다. 일부 실시예에서, 관리자 도메인(364)은 상태 리포트를 생성하기 위해 MDR 시스템(320)에 대한 질의를 생성하는 모니터링 엔진을 포함할 수 있다. 예를 들어, 관리자 도메인(364)의 모니터링 엔진은 (1) PDD를 누락하였거나, (2) 완료되었거나 (3) 창고로부터 배송된 주문에 대한 상태 리포트를 요청하기 위해 MDR 시스템(320)에 대한 API 호출을 발행할 수 있다. 일부 실시예에서, 모니터링 엔진은 API 요청의 일부로서 상태 카테고리를 지정할 수 있다. 예를 들어, 모니터링 엔진은 리턴 되어야 하는 상태의 유형을 지정하는 REST API GET에 속성을 포함할 수 있다. 대안적으로, 또는 추가적으로, 관리자 도메인(364)은 MDR 데이터베이스(325)에서 상태 테이블을 리포팅 하고 질의하기 위해 미리 정의된 작업을 조정할 수 있다.
특정 실시예에서 MDR 시스템(320)은, 보안 위험을 최소화하고 네트워크(700)에서 정보를 보다 엄격하게 제어하기 위해, 관리자 도메인(364)을 통해서만 이용 가능할 수 있다. 예를 들어, MDR 시스템(320)의 REST API는 관리자 도메인(364)으로부터의 통신에만 노출될 수 있다.
더욱이, 도 7에 도시된 바와 같이, 특정 실시예에서 각각의 로컬 도메인(360)은 서브 도메인으로 세분화 될 수 있다. 예를 들어, 구매 도메인(361)은 구매 서비스 서브 도메인(361-1) 및 구매 수신자 서브 도메인(361-2)으로 구분될 수 있다. 이러한 실시예에서, MDR 시스템(320)은 서브 도메인으로부터의 메시지를 특정 상태와 자동으로 연관 시키도록 구성될 수 있다. 예를 들어, 구매 서비스 서브 도메인(361-1)으로부터의 페이로드에 관계없이 모든 메시지는 "상태 A"와 연관될 수 있는 반면, 구매 수신자 서브 도메인(361-2)으로부터의 메시지는 "상태 B"와 연관될 수 있다. 이러한 실시예에서, 그럼에도 불구하고 감소된 페이로드를 갖는 도메인으로부터의 메시지는 MDR 시스템(320)에서 주문 또는 모니터링 엔티티의 상태에서 업데이트를 트리거 할 수 있다. 유사하게, 주문 도메인(363)은 주문 서비스 서브 도메인(363-1) 및 주문 수신기 서브 도메인(363-2)으로 구분될 수 있고, 각각 MDR 시스템(320)의 업데이트를 위한 서로 다른 트리거와 연관될 수 있다. 또한, 재고 도메인(362)은 재고 서비스 서브 도메인(362-1) 및 재고 수신기 도메인(362-2)으로 구분될 수도 있고, 각 서브 도메인이 특정 트리거링 업데이트와 연관될 수 있다. 업데이트를 트리거 하는 것은 API 호출을 이용하여 MDR 시스템(320)을 통해 MDR 데이터베이스(325)로 업데이트를 전송하는 것을 포함할 수 있다.
도 8은 개시된 실시예에 따른, MDR 시스템(320)(도 3)을 이용하여 주문 배송을 모니터링 하기 위한 예시적인 프로세스(800)의 흐름도이다.
프로세스(800)는 클라이언트 디바이스(350) 중 하나 이상에 의해 네트워크(370)에 주문이 있을 때 개시될 수 있다. 예를 들어, 클라이언트 디바이스(350)는 아이템을 구매하기 위해 네트워크에서 주문을 할 수 있다. 일부 실시예에서, 주문은 시스템(100)의 요소를 통해 수신될 수 있다. 예를 들어, 주문은 외부 프론트 엔드 시스템(103)(도 1)으로부터 수신될 수 있다. 주문은 배송 위치 및/또는 고객 선호도와 같은 정보를 포함할 수 있다.
주문은, 고객 주문을 수신하고 처리할 수 있는 주문 도메인(363)(도 6)과 같은, 로컬 도메인(360)으로 중계될 수 있다. 일부 실시예에서, 도 8에 도시 된 바와 같이, 로컬 도메인(360)은, 클라이언트 주문 처리를 담당하는 로컬 도메인(360)의 서버일 수 있는, 주문 발행자(802)를 포함할 수 있다. 예를 들어, 주문 발행자(802)는 FO 시스템(113), SAT 시스템(101) 및/또는 이행 메시징 게이트웨이(115) 중 임의의 것으로 구현될 수 있다. 특정 실시예에서 주문 발행자(802)는 도 15와 관련하여 추가로 논의되는 바와 같이, FC를 식별함으로써 주문 처리하기 위해 SAT 시스템(101)(도 1)으로 구현될 수 있다. 주문 발행자(802)는, 재고 도메인(362) 및 구매 도메인(361)과 같은, 추가적인 로컬 도메인(360)과 통신할 수 있다.
도 8에 도시된 바와 같이, 일부 실시예에서 주문 발행자(802)는 모니터링 이벤트 엔티티를 생성하기 위해 MDR 시스템(320)에 대한 제1 메시지 또는 호출(806)을 생성하도록 구성될 수 있다. 일부 실시예에서, 제1 메시지 또는 호출(806)은 주문의 초기 상태를 포함할 수 있다. 예를 들어, 제1 메시지 또는 호출(806)은 창고로 전송된 주문에 대한 상태를 지정할 수 있다. 주문 발행자(802)는 주문이 수신되고/되거나 주문이 창고로 전송되는 즉시 자동으로 제1 메시지 또는 호출(806)을 전송하도록 구성될 수 있다. 일부 실시예에서, 도 6과 관련하여 개시된 바와 같이, 로컬 도메인(360)(예를 들어, 주문 도메인(363))은 자동화된 디스커버리 동작에서 메시지 또는 호출(806)을 생성하도록 구성될 수 있다.
제1 메시지 또는 호출(806)을 전송하는 것 외에도, 주문 발행자(802)는 제2 메시지 또는 호출(808)을 창고로 전송할 수 있으며, 이는, 풀필먼트 센터 도메인과 같은, 로컬 도메인 중 다른 하나에 있을 수 있다(예를 들어, 제2 메시지 또는 호출(808)은 FO 시스템(113)으로 전송될 수 있음).
창고 또는 풀필먼트 센터 도메인(FO 시스템(113)과 같은)이 단계 814에서 창고로부터 배송되면, 풀필먼트 센터 도메인은 주문이 배송되었음을 로컬 도메인(360) 중 하나에 알리는 제3 메시지 및 호출(810)을 생성할 수 있다. 예를 들어, 풀필먼트 센터(FC) 도메인은 배송 업데이트 수신기(804)를 포함할 수 있는 배송 도메인에 제3 메시지 또는 호출(810)을 전송할 수 있다. 그런 다음 배송 업데이트 수신기(804)는 제4 메시지 또는 호출(812)을 MDR 시스템(320)에 전송할 수 있다. 제4 메시지 또는 호출(812)은(제1 메시지 또는 호출(806)을 통해) 모니터링 되고 있는 주문이 배송되었음을 지정할 수 있다. 일부 실시예에서, 제4 메시지 또는 호출(812)은 모니터링 엔티티를 업데이트하는 MDR 시스템(320)의 노출된 REST API 통신을 통해 전송될 수 있으며, 이는 MDR 상태 테이블(656)의 아이템 중 하나로 구현될 수 있다. MDR 시스템(320)이 제1 메시지 또는 호출(806) 및 제4 메시지 또는 호출(812)을 수신함에 따라, MDR 프로세서(322)는 MDR 데이터베이스(325)에 엔트리를 생성하고 주문 상태를 업데이트 할 수 있다.
프로세스(800)에서 서로 다른 도메인으로부터의 메시지 또는 호출의 상기 구성은, MDR 시스템(320)이 이벤트를 중앙 집중식 소스로 수렴함으로써 중단된 워크 플로우를 모니터링 할 수 있게 한다. 이러한 구성은 관리자 도메인(364)이 시스템(300)에 의해 처리되고 있는 하나 또는 다수의 주문에 대한 실시간, 주기적 및/또는 요청 시 상태 요청을 생성할 수 있게 한다. 더욱이, 개시된 구성은 관리자 도메인(364)이 구매 주문을 모니터링하고/하거나 재고를 모니터링 할 수 있게 한다. 따라서, 프로세스(800)는 MDR 데이터베이스(325)에서 모니터링 된 주문의 상태를 요청하기 위한 메시지 또는 호출을 생성하기 위한 구성 가능한 스케줄링 된 모니터링 작업을 포함할 수 있다. 예를 들어, 주기적으로(또는 요청 시) 관리자 도메인(364)은 MDR 시스템(320)에 대한 리포트 요청을 생성할 수 있다. 예를 들어, MDR 시스템(320)은 누락된 모니터링 엔트리(816)에 대한 리포트를 생성할 수 있으며, 그런 다음 이 리포트는 관리자 네트워크(364)에서 브로드캐스트 된 이메일로 전달될 수 있다.
도 8에 도시된 바와 같이, 일부 실시예에서, 관리자 네트워크(364)는 모니터링 작업의 구성 가능한 스케줄링을 포함할 수 있다. 예를 들어, 관리자 네트워크(364)는 사용자 구성 주기로 상태 요청을 생성하도록 구성 가능한 서버 및/또는 프로세스를 호스팅 할 수 있다. 일부 실시예에서, 관리자 네트워크(364)의 구성 가능한 스케줄링 된 모니터링 작업은 구성 가능한 스케줄링 된 모니터링 작업에서 프로그래밍 될 수 있는 사용자 선호도에 기초하여 주기적으로 요청을 생성할 수 있다. 일부 실시예에서, 구성 가능한 스케줄링 된 모니터링 작업은 구성 가능한 기간 또는 간격(예를 들어, 매일 또는 매시간)으로 상태 테이블을 질의 하기 위한 자동화 소프트웨어, 스크립팅 및/또는 파이프 라인 프로그래밍을 포함할 수 있다. 예를 들어, 구성 가능한 스케줄링 모니터링은 MDR 상태 테이블(656)(도 6)의 주문으로부터 상태 요청을 프로그래밍 할 수 있다. 또한, 구성 가능한 스케줄링 된 모니터링 작업은 상태 테이블로부터 데이터를 요청할 뿐만 아니라 원하는 영수증에 대한 리포트도 생성할 수 있다. 이러한 실시예에서, 자동화 소프트웨어는 작업 요청에 응답하여 수신된 정보에 기초하여 리포트를 분석하고 생성하도록 관리자 네트워크(364)의 요소를 구성할 수 있다. 예를 들어, MDR 상태 테이블(656)이 주문 및 관련된 약속된 배달 날짜를 가질 때, 관리자 네트워크(364)는 상태 테이블로부터 데이터를 수집한 다음 리포트를 창고로 보내도록 구성될 수 있다. 대안적으로, 또는 추가적으로, 구성 가능한 스케줄링 된 모니터링 작업은 주문의 상태, 보고 주기 및/또는 경보에 기초하여 리포트의 생성 및 배달을 프로그래밍 할 수 있다.
일부 실시예에서, 관리자 네트워크(364)는 중단이 없는 한 매 간격마다 상태 테이블을 질의하는 Jenkins 작업(예를 들어, 코드 또는 자동화 소프트웨어로서의 파이프 라인)을 이용하여 스케줄링 작업을 구성할 수 있다. 예를 들어, 관리자 네트워크(364)는 24, 12, 6 또는 3 시간 등 마다 실행되는 Jenkins 작업을 구성할 수 있다. 이러한 실시예에서, Jenkins 작업은, 보고서를 생성하기 위한, 상태 테이블 및 주기성 또는 조건으로부터 요청 데이터의 동작을 수행할 수 있다.
프로세스(800)는 나중에 관리자 도메인(364)에 리포팅 하기 위해 주문 요청 및 배송을 모니터링 하기 위한 MDR 시스템(320)의 예시적인 이용을 설명한다. 그러나, 프로세스(800)는 서로 다른 동작 또는 연결 해제된 워크 플로우에 대해 조정될 수 있다. 예를 들어, 프로세스(800)는 구매 주문을 모니터링하고/하거나 재고를 모니터링 하도록 조정될 수 있다.
도 9는 개시된 실시예에 따른, 자동화된 디스커버리 동작을 통해 다중 도메인 네트워크에서 복수의 도메인들과의 통신을 구성하기 위한 예시적인 프로세스 흐름(900)의 타이밍도이다.
일부 실시예에서, 도 9에 도시된 바와 같이, 시스템(300)(도 3)의 서로 다른 요소 및 서로 다른 로컬 도메인(360)은 프로세스 흐름(900)의 특정 단계들을 수행할 수 있다. 예를 들어, MDR 시스템(320)의 구성 요소는 프로세스 흐름(900)의 하나 이상의 단계를 수행할 수 있고, 로컬 도메인(360)(예를 들면, 구매 도메인(361), 재고 도메인(362), 주문 도메인(363), 및 관리자 도메인(364)과 같은)은 프로세스 흐름(900)의 추가적인 단계를 수행할 수 있다. 그러나, 다른 실시예에서, 시스템(300)의 대안적인 요소가 설명된 단계들(예를 들면, 데이터베이스(380)가 특정 단계들을 수행할 수 있음)을 수행할 수 있거나 시스템(300)의 단일 요소가 설명된 단계들을 수행할 수 있다.
단계 902에서 MDR 시스템(320)은 디스커버리 신호를 브로드캐스트 할 수 있다. 예를 들어, MDR 시스템(320)은 네트워크 및 대응하는 네트워크 된 디바이스에서 도메인을 식별하기 위해 디스커버리 신호를 생성할 수 있다. 일부 실시예에서, 단계 920의 디스커버리 신호는 데이터 패킷을 네트워크에 포함 된 모든 IP 주소로 브로드 캐스팅하는 UDP 브로드캐스트 신호일 수 있다. 대안적으로, 또는 추가적으로, 단계 902의 디스커버리 신호는 TCP 디스커버리 신호를 포함할 수 있다. 일부 실시예에서, 디스커버리 신호는 다중 도메인 네트워크의 도메인 각각에 대한 변수를 생성하는 동작을 포함할 수 있다. 예를 들어, MDR 시스템(320)은 new IPEndPoint(IPAddress.Any, 0), Server.Receive(ref ClientEp) 및 Encoding.ASCII.GetString(ClientRequestData)와 같은 동작을 포함 할 수 있다.
단계 904-910에서, 로컬 도메인(360)은 구성 템플릿으로 브로드캐스트 디스커버리 요청에 응답할 수 있다. 구매 도메인(361)은 단계 904에서 제1 구성 템플릿으로 디스커버리 요청에 응답할 수 있다. 제1 구성 템플릿은 구매 도메인(361)과 연관되어 있다. 재고 도메인(362)은 단계 906에서 제2 구성 템플릿으로 디스커버리 요청에 응답할 수 있다. 제2 구성 템플릿은 재고 도메인(362)과 연관되어 있다. 유사하게, 주문 도메인(363)은 단계 908에서 제3 구성 템플릿으로 디스커버리 요청에 응답할 수 있다. 제3 구성 템플릿은 주문 도메인(363)과 연관되어 있다. 그리고 관리자 도메인(364)은 단계 910에서 제4 구성 템플릿으로 디스커버리 요청에 응답할 수 있다. 제4 구성 템플릿은 관리자 도메인(364)과 연관되어 있다.
구성 템플릿은 로컬 도메인(360) 및/또는 제3자 도메인(365)에 있는 네트워크 디바이스의 정보를 제공할 수 있다. 또한, 구성 템플릿은 로컬 도메인(360)에서 네트워크 토폴로지 및 가용 리소스를 나타낼 수 있다. 구성 템플릿은 또한 네트워크 내의 특정 디바이스에 대한 프로그래밍 명령을 포함할 수 있다. 명령은 도메인 간 통신을 생성하기 위해 도메인의 시스템을 프로그래밍하는 방법을 제공할 수 있다.
단계 912에서, MDR 시스템(320)은 리포팅 서비스에 도메인을 추가할 수 있다. 예를 들어, 단계 912에서 MDR 시스템(320)은 로컬 도메인(360)과 연관된 상태(state)에 대한 상태(status)을 포함 할 수 있고 단계 902에서 디스커버리 된 도메인으로부터의 REST API 요청에 그 자신을 노출할 수 있다. 또한 단계 914에서 MDR 시스템(320)은 추가된 도메인에 대한 답신을 브로드캐스트 할 수 있다.
단계 916 및 918에서, MDR 시스템(320)은 연결 해제된 워크 플로우의 중앙 집중식 모니터링을 허용하는 자동화된 도메인 간 통신을 프로그래밍하기 위해 설정(configurations)을 로컬 도메인(360)으로 전송할 수 있다. 예를 들어, 단계 916에서 MDR 시스템(320)은 자동화된 통신을 위해 구매 도메인(361) 및 개방 포트로 생성 요청 구성을 전송할 수 있다. 유사하게, 단계 918에서 MDR 시스템(320)은 주문 모니터링을 위한 자동화된 통신을 위해 재고 도메인(362) 및 개방 포트로 업데이트 요청 구성을 전송할 수 있다. 결국, 로컬 도메인은 네트워크 된 요소가 주문 모니터링을 위한 자동화된 통신을 위해 구성되었음을 도메인 확인으로 응답할 수 있다. 예를 들어, 단계 920에서 구매 도메인(361)은 제1 도메인 형태로 응답할 수 있고 단계 922에서 재고 도메인(362)은 제2 도메인 확인으로 응답할 수 있다. 단계 916-922를 통해, MDR 시스템(320)은 MDR 데이터베이스(325)에 상태 및 엔트리를 생성하고 데이터의 최소화된 교환과 대역폭 가용성에 대한 낮은 영향으로 다중 도메인 네트워크의 중앙 집중식 모니터링 시스템을 생성하도록 자동화된 메시징 시스템을 설정할 수 있다.
일부 실시예에서, MDR 시스템(320)은 프로세스 흐름(900)의 일부로서 추가 도메인에 대해 유사한 구성을 수행할 수 있다. 예를 들어, 단계 926에서 MDR 시스템(320)은 자동화된 통신을 위해 구매 요청 구성을 주문 도메인(363) 및 개방 포트로 전송할 수 있다. 또한, 단계 928에서 MDR 시스템(320)은 자동화된 통신을 위해 재고 요청 구성을 관리자 도메인(364) 및 개방 포트로 전송할 수 있다. 주문 도메인(363) 및 관리자 도메인(364)은 각각 단계 930 및 932에서 도메인 확인으로 MDR 시스템(320)에 응답할 수 있다.
단계 934에서, MDR 시스템(320)은 다중 도메인 네트워크의 디스커버리 된 및 연결된 도메인 사이의 이벤트 조합에 대한 상태 필드를 갖는, MDR 상태 테이블(656)과 같은, 상태 테이블을 생성 할 수 있다. 예를 들어, MDR 시스템(320)은 중앙 집중식 모니터링 서비스를 제공하기 위해 상태 변수 및 자동화된 통신을 이용하여 중단된 워크 플로우를 통해 주문의 진행을 모니터링 하는 상태 테이블을 생성할 수 있다.
일부 실시예에서, 프로세스 흐름(900)은 MDR 시스템(320)이 리포팅 시스템을 생성하는 자동화된 통신을 위해 네트워크의 다수의 도메인을 구성하도록 허용할 수 있다. 예를 들어, 프로세스 흐름(900)은 MDR 시스템(320)이 도메인과 연결되고 연결 해제된 워크 플로우를 통해 주문을 추적하기 위해 REST API 서비스를 노출할 수 있게 한다.
도 10은 개시된 실시예에 따른, 도메인 요청을 처리하고 경보를 생성하기 위한 예시적인 프로세스 흐름(1000)의 타이밍도이다.
일부 실시예에서, 도 10에 도시된 바와 같이, 시스템(300)(도 3)의 서로 다른 요소 및 로컬 도메인(360)의 서로 다른 요소는 프로세스 흐름(1000)의 특정 단계들을 수행할 수 있다. 예를 들어, MDR 시스템(320)의 구성 요소는 프로세스 흐름(1000)의 하나 이상의 단계를 수행할 수 있고, 로컬 도메인(360)(주문 도메인(363), 재고 도메인(362) 및 관리자 도메인(364)과 같은)은 프로세스 흐름(1000)의 추가적인 단계들을 수행할 수 있다. 그러나, 다른 실시예에서, 시스템(300)의 대안적인 요소가 설명된 단계들을 수행할 수 있거나(예를 들어, 데이터베이스(380)는 특정 단계들을 수행할 수 있음) 시스템(300)의 단일 요소가 설명된 단계들을 수행할 수 있다.
특정 실시예에서, 프로세스 흐름(1000)은 프로세스 흐름(900) 후에 수행될 수 있다. 예를 들어, MDR 시스템(320)은 프로세스 흐름(900)을 이용하여 다중 도메인 네트워크를 구성할 수 있고, 프로세스 흐름(900) 구성 후에, MDR 시스템(320)은 프로세스 흐름(1000)을 통해 주문의 상태를 모니터링 할 수 있다.
단계 1002에서, 주문 도메인(363)은 주문 키를 포함하는 REST API 호출을 생성할 수 있다. 주문 키는 벤더 및/또는 아이템에 기초하여 인코딩 될 수 있다. 예를 들어, 주문의 유형에 따라, 주문은 주문을 이행하기 위해 다양한 벤더에 라우팅 될 수 있다. 주문의 각 아이템은 벤더에 기초하여 고유한 주문 키(예를 들면, 주문: 12345)가 할당될 수 있다. 주문 내의 이 아이템은 벤더 JIKGU, 벤더 Ingram, 벤더 EU_JIKGU 또는 기타에 할당될 수 있다. 따라서 아이템 주문의 주문 키는 12345, 12345_JIT_ING 또는 12345_EU_JIKGU가 될 수 있으며, 주문, 아이템 및 벤더를 코드화(codifying) 할 수 있다. 도 10에 도시된 바와 같이, 생성된 REST API 호출은 MDR 시스템(320)으로 전송될 수 있다.
단계 1004에서, MDR 시스템(320)은 PDD를 추정할 수 있다. 예를 들어, MDR 시스템(320)은 PDD를 생성하기 위해 특정 벤더 풀필먼트 센터, 창고 및/또는 제3자를 식별하여 위치 및/또는 이전 배달을 상관시킬 수 있다. 도 15와 관련하여 추가로 설명되는 바와 같이, PDD를 결정하는 것은 주문의 상태를 모니터링 하는데 이용될 수 있는 PDD를 추정하기 위해 선택 규칙에 기초한 풀필먼트 센터의 선택을 포함할 수 있다. 일부 실시예에서, PDD는 할당된 벤더에 기초할 수 있다. 예를 들어, 로컬 도메인(360)의 벤더에 의해 처리된 주문은 2일 PDD를 갖는 반면 제3자 도메인(365)에 의해 처리된 주문은 7일 PDD를 가질 수 있다.
단계 1006에서, MDR 시스템(320)은 상태 테이블에 엔트리 또는 모니터링 엔티티를 생성할 수 있다. 예를 들어, MDR 시스템(320)은 단계 1002의 REST API 호출에 응답하여 MDR 상태 테이블(656)에 엔트리를 생성할 수 있다. 일부 실시예에서, MDR 시스템(320)은 주문 도메인(363)에 의해 처리되고 있는 새로운 주문으로부터 모니터링 이벤트를 생성하기 위한 REST API 서비스를 노출할 수 있다.
단계 1008에서, MDR 시스템(320)은 배송 정보를 포함하는 재고 도메인(362)으로부터 REST API 호출을 수신할 수 있다. 예를 들어, 주문이 창고에서 택배 회사로 배송되면, 재고 도메인(362)은 주문과 연관된 모니터링 엔티티의 상태를 업데이트하기 위해 MDR 시스템(320)에 메시지를 전송할 수 있다. 예를 들어, MDR 시스템(320)은 도 8과 관련하여 설명된 바와 같이, 주문이 창고로부터 배송될 때 배송의 업데이트 상태를 수신할 수 있다. 일부 실시예에서, 프로세스 흐름(900)(도 9)에서 교환된 구성 템플릿은 재고 도메인(362)으로부터 MDR 시스템(320)으로 REST API 호출의 자동화된 전송을 허용할 수 있다. 일부 실시예에서, 단계 1008은 MDR 시스템(320)으로부터 모니터링 엔티티를 업데이트 하기 위해 노출된 REST API 서비스를 호출하는 것을 포함할 수 있다.
일부 실시예에서, 재고 도메인(362)으로부터의 REST API 호출은 MDR 시스템(320)에서 상태 변경을 트리거 할 수 있다. 예를 들어 주문의 상태는 "창고로 전송(SENT TO WAREHOUSE)"에서 "배송(SHIPPED)"으로 또는 "누락된(MISSED) PDD에서"에서 “완료 됨(COMPLETED)”으로 수정될 수 있다.
단계 1010에서, 관리자 도메인(364)은 리포트를 요청하기 위해 MDR 시스템(320)과 통신할 수 있다. 예를 들어, 관리자 도메인(364)의 모니터링 엔진은 "누락된 PDD" 상태를 갖는 주문으로 리포트에 대한 요청을 생성할 수 있다. 대안적으로, 또는 추가적으로, 관리자 도메인(364)은 코드화된 (codified) 상태의 주문에 대한 요청을 생성할 수 있다. 예를 들어, MDR 시스템(320)은 주문의 상태를 (1) 개시 됨, (2), 실패 및 (3) 완료 됨으로 코드화 할 수 있다. 단계 1010에서, 관리자 도메인(364)은 승인된 사용자가 MDR 시스템(320)으로부터 리포트를 요청할 때, 주기적으로(예를 들어, 영업일의 종료 시) 또는 요청 시 리포팅 명령을 전송할 수 있다.
단계 1012에서, MDR 시스템(320)은 단계 1010의 리포팅 명령에 따르는 모니터링 동작을 수행할 수 있다. 예를 들어, MDR 프로세서(322)(도 6)의 리포트 생성기(648)는 단계 1010의 리포팅 명령과 일치하는 주문 또는 티켓을 식별하기 위해 MDR 상태 테이블(656)을 통해 구문 분석할 수 있다. 일부 실시예에서, 단계 1012에서 리포트 생성기(648)는 "누락된 PDD"의 상태를 갖는 주문 또는 관리자 도메인(364)의 사용자에 대한 리포트 준비 실패를 식별할 수 있다.
단계 1014에서, MDR 시스템(320)은 경보를 생성할 수 있다. 예를 들어, MDR 시스템(320)은 리포팅 명령과 일치하는 상태를 갖는 주문을 포함하는 이메일 또는 텍스트 메시지를 생성할 수 있다. 단계 1016에서, MDR 시스템(320)은 관리자 도메인(364)에 경보를 전송할 수 있다.
프로세스 흐름(1000)은 MDR 시스템(320)이 다중 도메인 네트워크에서 중앙 집중식 모니터링 시스템을 생성할 수 있는 방법의 예를 도시한다. 비록 주문 도메인(363) 및 재고 도메인(362)이 표준화된 통신 없이 중단된 워크 플로우를 수행하더라도, MDR 시스템(320)은 다중 도메인 네트워크의 관리자가 단순화되고 자동화된 통신으로 주문 또는 티켓의 상태를 모니터링 할 수 있게 한다. 따라서, MDR 시스템(320)의 구현은 관리자가 다중 도메인 네트워크에서 이벤트를 조정하는 능력을 개선한다.
도 11은 개시된 실시예에 따른, MDR 데이터베이스(325)와 같은, 데이터베이스에 저장된 다중 도메인 모니터링을 위한 예시적인 상태 테이블(1100)이다. 상태 테이블(1100)은 모니터링 엔티티(1102)라고 하는 공동의 복수의 엔트리 또는 모니터링 엔티티(1102(a)-1102(z))를 포함한다. 상태 테이블(1100)은 각각의 모니터링 엔티티(1102)를, 주문 또는 티켓 상태의 중앙 집중식 모니터링을 위해 이용될 수 있는 복수의 필드와 연관시킬 수 있다.
도 11의 개별 요소를 참조하기 위해 이용되는 리터럴(Literals), 예를 들어, (a), (b) 또는 (z)는, 상태 테이블(1100)에서 요소의 수 또는 총 요소 수를 지정하지 않는다. 대신, 그것들은 변수 요소 수와 전체 요소의 변수 수를 나타내는 변수 참조이다. 예를 들어, 모니터링 엔티티(z)를 참조하는데 이용되는 리터럴(z)은 모니터링 엔티티(z)가 26 번째 메모리 단위임을 나타내지 않는다. 대신, (z)는 임의의 정수를 나타낼 수 있는 변수 참조이다. 따라서, 모니터링 엔티티(z)는 모니터링 엔티티(1102) 또는 엔트리 중 임의의 하나이다.
상태 테이블(1100)의 필드는 필드 ID(1110), 엔티티 유형 필드(1112), 엔티티 필드(1114) 및 현재 상태 필드(1116)를 포함할 수 있다. 필드 ID(1110)는 각 행에 대해 고유한 기본 키를 저장할 수 있다. 대안적으로, 또는 추가적으로, 필드 ID(1100)는 도 10과 관련하여 추가로 설명되는 바와 같이, 벤더 및/또는 아이템에 기초하여 인코딩 된 주문 키를 저장할 수 있다. 엔티티 유형 필드(1112)는 모니터링 되고 있는 엔티티/이용 사례의 유형(예를 들어, JIKGU_ORDER_MONITOR, INVENTORY_MONITOR, PURCHASE_MONITOR)을 저장할 수 있다. 엔티티 필드(1114)는 모니터링 되고 있는 실제 엔티티 값(예를 들어, 실제 주문 ID 또는 12345_JIT_ING)을 저장할 수 있다. 또한, 현재 상태 필드(1116)는 엔티티 모니터링의 상태(예를 들어, ORDER_SENT_TO_WAREHOUSE)를 저장할 수 있다. 추가적으로, 또는 대안적으로, 현재 상태 필드(1116)의 값은 널(null) 값, 창고 값으로 전송된 주문, 배송된 주문 값, 누락된 PDD 값 또는 완료된 값을 포함하는 그룹으로부터 선택될 수 있다.
상태 테이블(1100)은 또한, 엔티티가 그것을 완료하기 위해 도달해야 하는 예상 최종 상태(예를 들어, ORDER_SHIPPED)를 저장할 수 있는, 예상 상태 필드(1118)를 포함할 수 있다. 일부 실시예에서, 예상 상태 필드(1118)는 ML 트레이너(646)에 의해 트레이닝 된 머신-러닝 알고리즘으로부터의 결과에 기초하여 채워질 수 있다. 예를 들어, 예상 상태 필드(1118)는 ML 모델 출력에 기초하여 주문에 대한 예측 상태를 저장할 수 있다. 상태 테이블(1100)은 또한 ML 모델을 활용하여 상태 테이블(1100)의 필드를 채울 수 있는 예상 종료 시간 필드(1122)를 포함할 수 있다. 대안적으로, 또는 추가적으로, 예상 종료 시간 필드(1122)는, 예상 상태 필드(1118)에 저장된, 예상 상태에 도달해야 하는 예상 종료 시간을 저장할 수 있다.
상태 테이블(1100)은 다중 도메인 네트워크의 서로 다른 단계에서 시간을 모니터링 하는 필드를 추가로 포함할 수 있다. 예를 들어, 상태 테이블(1100)은, 현재 상태 필드(1116)가 업데이트 된 실제 시작 시간을 저장하는, 시작 시간 필드(1120) 및, 예상 상태 필드(1116)에 저장된 상태에 도달해야 하는 실제 종료 시간을 저장할 수 있는, 종료 시간 필드(1124)를 포함할 수 있다.
상태 테이블(1100)은 또한 모니터링 엔티티(1102)에 대한 코드화된 상태를 포함할 수 있다. 예를 들어, MDR 시스템(320)은 상태 테이블(1100)의 필드의 조합에 기초하여 모니터링 엔티티(1102) 각각에 대한 코드를 생성할 수 있다. 상태 테이블(1100)은 모니터링 엔티티(1102)와 연관된 주문 또는 티켓의 상태를 인코딩 하는 코드화된 변수를 저장하는 상태 필드(1126)를 포함할 수 있다. 예를 들어, 상태 필드(1126)는 정수 변수를 저장할 수 있는데, 여기서 "1"은 시작된 주문을 코드화하고, "2"는 PDD 충족 실패를 코드화하고, “3”은 완료된 주문을 코드화한다. 더욱이, 특정 실시예에서 상태 필드(1126)는 널 값, 창고 값으로 전송된 주문, 배송된 주문 값, 누락된 PDD 값 또는 완료된 값을 포함하는 그룹으로부터의 값을 저장할 수 있다.
도 12는 개시된 실시예에 따른, 다중 도메인 상태 모니터링을 위한 예시적인 프로세스(1200)의 흐름도이다. 일부 실시예에서, 시스템(300)의 요소는 프로세스(1200)를 수행할 수 있다. 예를 들어, 아래의 단계 설명에 개시되는 바와 같이, MDR 시스템(320)은 프로세스(1200)를 수행할 수 있다. 대안적으로, 또는 추가적으로, 로컬 도메인(360)은 프로세스(1200), 또는 프로세스(1200)의 일부를, 수행할 수 있다. 또한, 다른 실시예에서 시스템(100), 또는 시스템(100)의 일부는, 프로세스(1200)를 수행할 수 있다. 예를 들어, SAT 시스템(101) 및/또는 FMG(115)는 프로세스(1200)를 수행할 수 있다.
단계 1202에서, MDR 시스템(320)은 제1 도메인 및 제2 도메인과의 연결을 설정할 수 있다. 예를 들어, MDR 시스템(320)은 MDR 프로세서(322) 또는 통신 디바이스(324)를 이용하는 자동화된 디스커버리 동작을 통해 로컬 도메인(360) 및/또는 제3자 도메인(365)과의 연결을 설정할 수 있다. 일부 실시예에서, 제1 도메인은 주문 수신 도메인을 포함하고 제2 도메인은 주문 배송 도메인이다. 이러한 실시예에서, 1202 MDR 시스템(320)은 단계 1202에서 배송 업데이트 수신기에서 하나 이상의 포트를 개방함으로써 제2 도메인과의 연결을 설정할 수 있다.
단계 1204에서, MDR 시스템(320)은 도메인이 자동화된 요청을 위해 구성되었는지 여부를 결정할 수 있다. 예를 들어, MDR 시스템(320)은(도 9와 관련하여 논의된 바와 같이) 시스템으로부터의 확인을 검토하여 디스커버리 된 도메인이 서비스에 의해 트리거 되는 자동화된 통신 또는 API 호출을 위해 구성되었는지 또는 주문 또는 티켓과 연관된 이벤트를 수신 하는지를 결정할 수 있다. MDR 시스템(320)이 도메인이 자동화된 요청에 대해 구성되지 않았다고 결정하면(단계 1204 : 아니오), MDR 시스템(320)은 단계 1206에서 관리자 네트워크에 통지할 수 있다. 예를 들어, 단계 1206에서 MDR 시스템(320)은 네트워크에서 하나 이상의 도메인이 구성되지 않았음을 나타내는 메시지를 관리자 네트워크(364)에 브로드캐스트 할 수 있다.
그러나, MDR 시스템(320)은 도메인이 자동화된 요청에 대해 구성되었다고 결정하면(단계 1204 : 예), MDR 시스템(320)은 단계 1208로 계속할 수 있다. 단계 1208에서, MDR 시스템은 주문 상태 이벤트 생성, 주문 상태 이벤트 업데이트 및/또는 주문 상태 이벤트 리포팅을 위해 REST API 또는 큐 기반 서비스를 노출할 수 있다. 예를 들어, 도메인이 자동화된 요청에 대해 구성되었을 때, MDR 시스템(320)은 모니터링 엔티티(1102) 중 하나를 생성하고, 모니터링 엔티티를 업데이트(예를 들어, REST API 호출을 통해)하고, 리포트 요청을 수신 및 처리하기 위해 REST API를 노출할 수 있다.
단계 1210에서, MDR 시스템(320)은 거래와 연관된 모니터링 동작을 개시하기 위해 제1 도메인으로부터 생성 요청을 수신할 수 있다. 예를 들어, 도 10과 관련하여 추가로 논의된 바와 같이, 로컬 도메인(360) 중 하나는 클라이언트 디바이스(350) 중 하나로부터 수신된 주문과 연관된 생성 요청을 생성할 수 있다. 일부 실시예에서, 제1 요청은 주문 키를 포함하는 제1 REST API 호출을 포함하며, 여기서 주문 키는 아이템 ID 및 벤더 ID를 인코딩 한다.
일부 실시예에서, MDR 시스템(320)은 단계 1210에서 제1 도메인으로부터 생성 요청을 수신하는 것에 응답하여 상태 테이블(1100)에 엔트리를 자동으로 생성할 수 있다. 이러한 실시예에서, MDR 시스템(320)은 벤더 ID, 현재 시간 및 시작 시간에 기초하여 예상된 완료 필드의 값을 추정하는 것에 의해 상태 테이블(1100)에 새로운 엔트리를 생성할 수 있다.
단계 1212에서, MDR 시스템(320)은 벤더 ID, 현재 시간 및 풀필먼트 센터에 기초하여 PDD를 추정할 수 있다. 예를 들어, MDR 시스템(320)은 생성 요청과 연관된 주문 키로부터 주문 및 벤더에 대해 선택된 풀필먼트 센터를 식별하고 PDD를 결정할 수 있다. 일부 실시예에서, 도 15와 관련하여 추가로 논의되는 바와 같이, PDD의 결정은 풀필먼트 센터 선택, 아이템의 유형 및/또는 로컬 또는 제3자 도메인이 이행 요청을 처리하는지 여부에 대한 규칙에 기초할 수 있다.
단계 1214에서, MDR 시스템(320)은 데이터베이스에 저장된 상태 테이블에 새로운 엔트리 또는 모니터링 엔티티를 생성할 수 있다. 예를 들어, MDR 시스템(320)은 MDR 데이터베이스(325)에 저장된 상태 테이블(1100)에서 모니터링 엔티티(1102) 중 하나를 생성할 수 있다. 일부 실시예에서, 단계 1214에서 MDR 시스템(320)은 상태 테이블(1100)의 필드를 채울 수 있다. 예를 들어, MDR 시스템(320)은 상태 테이블(1100)의 필드를 채우기 위해 예상된 상태 및 예상된 종료 시간을 결정하는 ML 모델을 이용할 수 있다.
단계 1216에서, MDR 시스템(320)은 상태 테이블의 엔트리를 업데이트하기 위해 제2 도메인으로부터 업데이트 요청을 수신할 수 있다. 예를 들어, 도 10과 관련하여 논의된 바와 같이, MDR 시스템(320)은 제1 도메인과 다른 제2 도메인으로부터 API 호출을 통해 업데이트 요청을 수신할 수 있다. 제2 도메인은 배송 도메인 일 수 있는 반면 제1 도메인은 주문 도메인 일 수 있다. 제2 요청은 도 95에서 논의된 바와 같이, 주문의 상태를 지정하거나 "SHIPPED" 상태와 같은 특정 메시지를 전송할 수 있다. 더욱이, 일부 실시예에서 제2 요청은 배송 정보를 포함하는 제2 REST API 호출을 포함할 수 있다.
단계 1218에서, MDR 시스템(320)은 단계 1216의 업데이트 상태 요청과 연관된 상태 테이블에서 하나 이상의 엔트리를 식별할 수 있다. 예를 들어, MDR 시스템(320)은 업데이트 요청을 상태 테이블(1100)의 모니터링 엔티티(1102) 중 하나와 연관시킬 수 있다. 일부 실시예에서, MDR 시스템(320)의 MDR 프로세서(322)는 모니터링 엔티티(1102)의 필드 ID(1110)를 업데이트 요청의 ID와 상관시켜 상태 테이블(1100)의 어느 엔트리가 업데이트되어야 하는지를 식별할 수 있다.
일부 실시예에서, 단계 1210-1218은 새로운 주문이 다중 도메인 네트워크의 시스템에 의해 수신되고 처리됨에 따라 사이클(1240)에서 반복될 수 있다. 예를 들어, 단계 1210은 네트워크의 고객 페이싱 요소에 의해 새로운 주문 또는 티켓이 수신될 때마다 반복될 수 있다. 이러한 방식으로, 네트워크 관리자가 도메인을 통해 전체 상황 정보를 전달하지 않고도 주문의 상태를 모니터링 할 수 있게 하는 MDR 시스템(320)에 의해 관리되는 자동화된 중앙 집중식 모니터링 시스템을 생성 할 수 있다. 사이클(1240)을 이용하여 주문을 모니터링 하면 MDR 시스템(320)이 최소한의 필수 데이터로 상태를 단일 소스로 수렴할 수 있다. 이러한 구성은 대역폭 소비를 줄인 모니터링 시스템을 생성하여 다중 도메인 네트워크의 기술 분야를 개선한다.
사이클(1240)에서 프로세스(1200)의 모니터링 단계는 다중 도메인 네트워크에서 주문 또는 티켓의 상태를 식별하기 위해 관리자에 의해 질의될 수 있는, 상태 테이블(1100)과 같은, 상태 테이블을 준비할 수 있다. 단계 1220에서 MDR 시스템(320)은 모니터링 엔진으로부터 리포트 요청 및 카테고리 상태를 수신할 수 있다. 예를 들어, 도 10과 관련하여 논의된 바와 같이, 관리자 도메인(364)의 모니터링 엔진은 "MISSED PDD"의 카테고리 상태를 갖는 주문으로 리포트에 대한 요청을 주기적으로 생성할 수 있다. 일부 실시예에서, 단계 1220에서 수신된 카테고리 상태는 리포트 되어야 하는 모니터링 엔티티(1102)의 카테고리를 지정할 수 있다. 예를 들어, 네트워크의 관리자는 단계 1220의 요청에서 리포트 되어야 하는 필드를 지정할 수 있다. 일부 실시예에서, 상태 요청은 누락된 PDD 또는 널 종료 시간 중 적어도 하나를 포함할 수 있다. 또한, 관리자 도메인(364)의 모니터링 엔진은 적어도 하루에 한 번 및/또는 구성 가능한 빈도로 리포트 요청을 생성하도록 구성될 수 있다.
1222 단계에서, MDR 시스템(320)은 1220 단계의 요청 상태에서 상태 테이블의 적어도 하나의 엔트리가 카테고리 상태와 일치하는지 여부를 판단할 수 있다. 예를 들어, 리포트 요청이 'MISSED PDD'의 상태 카테고리를 포함하는 경우, MDR 시스템(320)은 모니터링 엔티티(1102) 중 적어도 하나가 'MISSED PDD'의 현재 상태 필드를 갖는지 여부를 결정할 수 있다. MDR 시스템(320)이 카테고리 상태와 일치하는 엔트리가 없다고 결정하면(단계 1222 : 아니오), MDR 시스템(320)은 단계 1206으로 계속하고, 예를 들어, 브로드캐스트 메시지를 발행함으로써 관리자 네트워크를 통지한다. 그러나, MDR 시스템(320)이 엔트리들 중 적어도 하나가 카테고리 상태와 일치한다고 결정하면(단계 1222 : 예), MDR 시스템(320)은 단계 1224로 계속할 수 있다.
단계 1224에서, MDR 시스템(320)은 상태 필드가 카테고리 상태와 일치하는 상태 테이블의 엔트리를 포함하는 경보를 생성할 수 있다. 예를 들어, MDR 프로세서(322)는 카테고리 상태와 일치하는 필드를 갖는 모니터링 엔티티(1102)를 포함하는 리포트를 생성하기 위해 리포트 생성기(648)를 이용할 수 있다. 도 17과 관련하여 추가로 논의되는 바와 같이, 경보는 관리자 도메인(364)에 배치될 수 있는 자동화된 이메일 또는 텍스트 메시지로서 브로드캐스트 될 수 있다. 일부 실시예에서, 단계 1224에서 경보를 생성하는 것은 관리자 네트워크에 이메일 메시지를 브로드캐스트 하는 것을 포함할 수 있다.
도 13은 개시된 실시예에 따른, 자동화된 디스커버리 연결을 통해 다중 도메인 통신을 설정하기 위한 예시적인 프로세스(1300)의 흐름도이다.
일부 실시예에서, 시스템(300)의 요소는 프로세스(1300)를 수행할 수 있다. 예를 들어, 아래의 단계 설명에 개시되는 바와 같이, MDR 시스템(320)은 프로세스(1300)를 수행할 수 있다. 대안적으로, 또는 추가적으로, 데이터베이스(380), 로컬 도메인(360), 또는 제3자 도메인(365)은 프로세스(1300), 또는 프로세스(1300)의 일부를, 수행할 수 있다. 또한, 다른 실시예에서 시스템(100), 또는 시스템(100)의 일부는, 프로세스(1300)를 수행할 수 있다. 예를 들어, 외부 프론트 엔드 시스템(103) 및/또는 FMG(115)는 프로세스(1300)를 수행할 수 있다.
단계 1302에서, MDR 시스템(320)은 네트워크 도메인과의 자동화된 디스커버리 연결을 시작할 수 있다. 예를 들어, MDR 시스템(320)은 주문 또는 티켓 상태의 중앙 집중식 모니터링을 허용하는 자동화된 도메인 간 통신을 설정하기 위해 자동화된 디스커버리 모듈(642)을 시작할 수 있다. 단계 1304에서, MDR 시스템(320)은 디스커버리 된 도메인과 연관된 구성 템플릿을 자동으로 디스커버 할 수 있다. 도 9와 관련하여 논의된 바와 같이, MDR 시스템(320)은 디스커버리를 브로드캐스트하고 다중 도메인 네트워크의 도메인으로부터 구성 템플릿을 수신할 수 있다.
단계 1306에서, MDR 시스템(320)은 모니터링 서비스에 도메인을 추가할 수 있다. 예를 들어, MDR 시스템(320)은 디스커버리 된 도메인들 간의 수 및 관계를 반영하기 위해 상태 테이블(1100)(도 11)에 필드를 추가할 수 있다. 또한, 단계 1306에서 MDR 시스템(320)은 디스커버리 된 도메인과 연관된 상태를 질의하는 방법을 생성할 수 있다. 단계 1308에서, MDR 시스템(320)은 주문 이벤트에 기초한 자동화된 메시지 및 도메인 구성을 위해 도메인의 통신 포트를 개방할 수 있다. 예를 들어, 일부 실시 예에서 MDR 시스템(320)은 다중 도메인 시스템에서 주문 또는 티켓 상태의 실시간 모니터링을 가능하게 하는 스트림 피드를 리포팅 하기 위해 로컬 도메인(360)에서 TCP 또는 UDP 포트를 개방할 수 있다.
단계 1310에서, MDR 시스템(320)은 주문을 수신하거나 풀필먼트 센터에 주문을 전송할 때 생성 요청을 생성하기 위해, 하나 이상의 웹 API를 통해, 제1 도메인을 구성할 수 있다. 예를 들어, MDR 시스템(320)은 클라이언트 디바이스(350)로부터 새로운 주문이 수신될 때마다 생성 요청을 전송하도록 주문 도메인(363)을 구성할 수 있다. 단계 1312에서, MDR 시스템(320)은 아이템이 배송될 때 업데이트 요청을 생성하기 위해, 하나 이상의 웹 API를 통해, 제2 도메인을 구성할 수 있다. 예를 들어, MDR 시스템(320)은 주문이 창고로부터 배송될 때마다 업데이트 요청을 전송하도록 재고 도메인(362)을 구성할 수 있다. 대안적으로, 또는 추가적으로, 단계 1310-1312는 새로운 주문이 수신되거나 주문이 풀필먼트 센터로 전송될 때 생성 요청을 생성하기 위해, 제1 도메인과 연관된 하나 이상의 웹 API를 통해, 제1 도메인을 구성하고, 아이템이 배송될 때 업데이트 요청을 생성하기 위해, 제2 도메인과 연관된 하나 이상의 웹 API를 통해, 제2 도메인을 구성하는 것을 포함할 수 있다.
단계 1314에서, MDR 시스템(320)은 추가 도메인이 네트워크에서 디스커버리 되었는지 여부를 결정할 수 있다. MDR 시스템(320)은 추가 도메인이 네트워크에서 디스커버리 되었다고 결정하면 (단계 1314 : 예), MDR 시스템(320)은 단계 1316으로 계속하여 추가 도메인과의 연결을 설정할 수 있다. 예를 들어, 단계 1316에서 MDR 시스템(320)은 관리자 도메인(364) 또는 제3자 도메인(365)과의 연결을 설정할 수 있다. 대안적으로, 또는 추가적으로, 단계 1316에서 MDR 시스템(320)은 자동화된 디스커버리 동작(도 9와 연결되어 설명된 것과 유사)을 수행함으로써 제3 도메인 및 제4 도메인과의 연결을 설정할 수 있고, 여기서 제3 도메인은 재고 도메인이고 제4 도메인은 제3자 도메인이다.
그러나, MDR 시스템(320)은 추가 도메인이 네트워크에서 발견되지 않았다고 결정하면(단계 1314 : 아니오), MDR 시스템(320)은 단계 1318로 계속하여 모니터링 테이블 및 상태 변수를 생성할 수 있다. 예를 들어, 단계 1318에서 MDR 시스템(320)은 MDR 상태 테이블(656)에서 필드의 수를 선택할 수 있다. 또한, MDR 시스템(320)은 MDR 상태 테이블(656)의 필드에서 가능한 변수 및 변수의 시퀀스를 코드화 할 수 있다. 예를 들어, MDR 시스템(320)은 "ORDER_SENT_TO_WAREHOUSE", "ORDER_SHIPPED", "ORDERS_MISSED_PDD" 및 "COMPLETED_ORDER"의 시퀀스를 포함할 수 있는, 예상될 수 있는 상태 필드(1126) 또는 현재 상태(1116)의 시퀀스를 인코딩 할 변수를 결정할 수 있다.
단계 1320에서, MDR 시스템(320)은 모니터링 엔진 요청에 기초하여 모니터링 동작을 개시할 수 있다. 예를 들어, 도 10 및 도 12와 관련하여 논의된 바와 같이, 관리자 도메인(364)의 모니터링 엔진은 리포팅 명령을 MDR 시스템(320)에 전송할 수 있다. 이에 응답하여, MDR 시스템(320)은 상태 테이블(1100)에서 모니터링 엔티티(1102)를 구문 분석하여 모니터링 동작을 수행하고 리포팅 명령과 일치하는 주문 또는 티켓으로 리포트를 준비할 수 있다. 일부 실시예에서, 모니터링 동작은 예상 완료 필드를 현재 시간과 비교하고 상태 필드의 값이 널 값 또는 누락된 PDD 값 중 적어도 하나인 상태 테이블의 엔트리를 식별하는 것에 기초하여 상태 테이블의 엔트리에 누락된 PDD 값을 할당하는 것을 포함할 수 있다. 추가적으로, 또는 대안적으로, 개시된 시스템의 특정 실시예는 자동화 서버를 통해 수행되고 있는 모니터링 동작을 가질 수 있다. 자동화 서버는 네트워크 된 개체의 프로그래밍 된 조작을 가능하게 하거나 네트워크 된 개체를 노출하여 그것들이 조작될 수 있다. 예를 들어, 자동화 서버는 프로그래밍 가능한 개체(자동화 개체라고 함)를 다른 애플리케이션(자동화 클라이언트라고 함)에 노출하는 애플리케이션을 실행할 수 있다. 일부 실시예에서, 자동화 개체를 노출하면 클라이언트는 서버가 이용 가능한 개체 및 기능에 직접 액세스함으로써 특정 절차를 자동화할 수 있게 한다. 이러한 방식으로 객체를 노출하면 애플리케이션이 다른 애플리케이션에 유용한 기능을 제공할 때 이로울 수 있다. 더욱이, 자동화 개체는 속성과 방법을 그것들의 외부 인터페이스로 가질 수 있다. 속성은 자동화 개체의 지명된 속성이다.
도 14는 개시된 실시예에 따른, 멀티 도메인 상태 테이블의 엔트리를 관리하기 위한 예시적인 프로세스(1400)의 흐름도이다. 예를 들어, 프로세스(1400)는 MDR 상태 테이블(656)을 채우기 위해 이용될 수 있다.
일부 실시예에서, 시스템(300)의 요소는 프로세스(1400)를 수행할 수 있다. 예를 들어, 아래의 단계 설명에 개시되는 바와 같이, MDR 시스템(320)은 프로세스(1400)를 수행할 수 있다. 대안적으로, 또는 추가적으로, 로컬 도메인(360) 또는 데이터베이스(380)의 요소는 프로세스(1400), 또는 프로세서(1400)의 일부를, 수행할 수 있다. 또한, 다른 실시예에서 시스템(100), 또는 시스템(100)의 일부는, 프로세스(1400)를 수행할 수 있다.
단계 1402에서, MDR 시스템(320)은 벤더, 풀필먼트 센터 및 고객에 기초하여 주문에 대한 고유 ID를 생성할 수 있다. 예를 들어, MDR 시스템(320)은 도 10과 관련하여 추가로 논의된 바와 같이, 벤더, 아이템 및 고객에 기초하여 주문 키를 코드화 할 수 있다.
단계 1404에서, MDR 시스템(320)은 모니터링 이용 사례에 대한 엔티티 유형을 결정할 수 있다. 예를 들어, MDR 시스템(320)은 주문 또는 티켓이 제품을 고객에게 배송하는 것과 연관되는지, 또는 그것이 제3자로부터 제품을 소싱하기 위한 엔티티 유형인지 여부를 결정할 수 있다.
단계 1406에서, MDR 시스템(320)은 실제 엔티티 식별자 또는 키를 결정할 수 있다. 예를 들어, MDR 시스템(320)은 MDR 시스템(320)이 주문과 연관된 업데이트 요청을 허용하는 상태 테이블에 대한 주문 ID를 결정할 수 있다.
단계 1408에서, MDR 시스템(320)은 주문에 대한 현재 상태 및 예상 상태를 결정할 수 있다. 예를 들어, MDR 시스템(320)은 엔티티가 시작되는 초기 상태(예를 들어, ORDER_SENT_TO_WAREHOUSE) 및 다음 업데이트를 수신할 때 예상 상태(예를 들어, ORDER_SHIPPED)를 결정할 수 있다.
단계 1410에서 MDR 시스템(320)은, 추정된 PDD에 기초할 수 있는, 시작 시간 및 예상된 종료 시간을 채울 수 있다. 단계 1412에서, MDR 시스템(320)은 주문이 시작, 완료 또는 실패했음을 나타내는 이벤트의 상태를 생성할 수 있다. 일부 실시예에서, 이벤트의 상태는 통신 교환의 페이로드를 최소화하거나 모니터링 동작 동안 알고리즘을 검색 또는 필터링 하는 것을 용이하게 하기 위해 코드화 될 수 있다. 단계 1414에서, MDR 시스템(320)은 주문 상태의 중앙 집중식 리포팅을 시작하기 위해 타이머를 초기화 할 수 있다.
단계 1416에서, MDR 시스템(320)은 MDR 시스템(320)에 의해 추적되는 주문 또는 티켓의 상태를 요청할 때 REST API 또는 큐 기반 입력을 서비스 도메인에 노출할 수 있다. 단계 1416은 API 모듈에 의해 노출될 시스템의 리소스를 식별, 노출된 리소스와 인터페이스 할 엔티티를 식별, 및 필요한 이용 사례를 개발하기 위해 API와의 상호 작용을 결정하는 것을 포함할 수 있다.
단계 1416은 또한 REST API를 통해 노출될 리소스의 각각의 위치를 식별하고 그들이 노출하는 리소스가 액세스 될 수 있는 URI 및 각각의 방법을 할당하는 것을 포함할 수 있다. 일부 실시예에서, URI는 기본적으로 경로이며, 시나리오에 대해 문맥적일 수 있다. 더욱이, REST API 입력 노출, MDR 시스템(320)은 특정 HTTP 방법을 이러한 경로 각각에 연관시킬 수 있으며, 여기서 각 방법은 특정 의미를 갖는다. HTTP 방법은 GET, POST, PUT 및/또는 DELETE를 포함할 수 있다.
일부 실시예에서, 단계(1416)의 REST API 또는 큐 기반 입력을 노출하는 것은 이 JSON 포맷으로 데이터를 생성하고 구문 분석 하기 위해 JavaScript에 기초한 클라이언트-사이드-프론트-엔드 기술을 구현하는 것을 포함할 수 있다. 예를 들어, MDR 시스템(320)은 JsonViewer, JsonCreator, JsonUpdater 및 JsonAdapter와 같은 인터페이스를 구현할 수 있다. 추가적으로, 또는 대안적으로, MDR 시스템(320)은 노출된 리소스에서 엔드 포인트를 식별하고 이러한 엔드 포인트에서의 호출(invocations)에 대한 JSON 응답을 생성하도록 구성될 수 있다. MDR 시스템(320)(MDR 데이터베이스(325)와 같은)의 이러한 구성 및 노출은 로컬 도메인(360) 및 제3자 도메인(365)이 중앙 집중식 모니터링을 위한 상태 테이블을 채우는 메시지를 생성할 수 있게 하고 또한 도메인이 MDR 시스템(320)의 리소스를 질의 할 수 있게 한다.
도 15는 개시된 실시에에 따른, 풀필먼트 센터의 할당 및 약속된 배달 날짜(PDD)를 결정하기 위한 예시적인 프로세스의 흐름도이다. 일부 실시예에서, 시스템(300)의 요소는 프로세스(1500)를 수행할 수 있다. 예를 들어, 아래 단계 설명에 개시되는 바와 같이, MDR 시스템(320)은 프로세스(1500)를 수행할 수 있다. 대안적으로, 또는 추가적으로, 로컬 도메인(360) 및/또는 제3자 도메인 (365)은 프로세스(1500), 또는 프로세스(1500)의 일부를, 수행할 수 있다. 또한, 다른 실시예에서 시스템(100), 또는 시스템(100)의 일부는, 프로세스(1500)를 수행할 수 있다. 예를 들어, SAT 시스템(101), FC Auth(123), 및/또는 FMG(115)(도 1a)는 프로세스(1500)를 수행할 수 있다.
단계 1502에서, MDR 시스템(320)은 배달 추정 정보 및/또는 PDD에 대한 요청을 수신할 수 있다. 요청은 제품, 시간 및 우편 번호 정보를 포함할 수 있다. 요청의 정보에 기초하여, MDR 시스템(320)은 단계 1504에서 관련 지리적 영역을 식별할 수 있다. 예를 들어, MDR 시스템(320)은 고객의 우편 번호에 기초하여 제품에 대한 잠재적 주문을 이행 할 수 있는 지역을 식별할 수 있다.
단계 1506에서, MDR 시스템(320)은 제품에 대한 잠재적인 주문을 완료할 수 있는 풀필먼트 센터를 식별할 수 있다. 일부 실시예에서, 단계 1504에서 식별된 지역은 다수의 풀필먼트 센터를 포함할 수 있다. 이러한 실시예에서, MDR 시스템(320)은 PDD를 충족시키는 능력 또는 요청된 제품의 가용성에 기초하여 풀필먼트 센터를 필터링 할 수 있다. 일부 실시예에서, 잠재적인 주문을 완료할 수 있는 풀필먼트 센터를 식별하는 것은 제품의 유형 및/또는 제품과 연관된 주문에 기초할 수 있다. 단계 1506에서 MDR 시스템(320)은 제품 식별이 특정 제품 유형 또는 특정 배달 시간 제품과 연관되는지 여부를 결정하고 특정 제품 유형의 가용성 또는 목적지 주소에 관한 풀필먼트 센터 위치에 기초하여 풀필먼트 센터를 식별할 수 있다. 예를 들어, 제품 식별이 특정 제품 유형과 연관되는 경우, MDR 시스템(320)은 원격 디바이스와 연관된 지역에 서비스를 제공하는 풀필먼트 센터를 식별하고, 풀필먼트 센터로부터 가용 특정 제품 유형 재고를 요청하고, 풀필먼트 센터 중 하나를 선택하는 동작을 수행할 수 있다. 대안적으로, 또는 추가적으로, 제품 식별이 특정 배달 시간 제품을 포함하는 경우, MDR 시스템(320)은 원격 디바이스에 가장 가까운 풀필먼트 센터를 식별하고, 원격 디바이스와 가장 가까운 풀필먼트 센터 사이의 거리 및 지역에 기초하여 컷오프를 결정하며, 1506 단계에서, 컷오프가 경과하지 않은 경우 가장 가까운 풀필먼트 센터를 선택하는 동작을 수행할 수 있다.
단계 1508에서, MDR 시스템(320)은 풀필먼트 센터에 대한 주문 할당 우선 순위 규칙을 실행할 수 있다. 일부 실시예에서, 할당 우선 순위 규칙은 MDR 시스템(320) 내의 메모리 디바이스에 저장될 수 있으며, 이는 단계 1504에서 식별된 지역(들)에 특정한 할당 규칙을 검색할 수 있다. 대안적으로, 또는 추가적으로, 할당 우선 순위 규칙은 데이터베이스(380)에 저장될 수 있고, MDR 시스템(320)은 일단 풀필먼트 센터가 단계 1506에서 식별되면 데이터베이스를 질의할 수 있다. 또 다른 실시예에서, 할당 규칙은 시스템(100)의 요소에 저장될 수 있다. 예를 들어, 할당 규칙은 FO 시스템(113)에 저장될 수 있다.
주문 할당 규칙은 지역의 각 풀필먼트 센터에 대한 우선 순위 점수를 생성할 수 있다. 우선 순위 할당 규칙은 선호도가 서로 다른 여러 규칙을 포함할 수 있다. 예를 들어, 주문 할당 규칙은, 계약된 배달 직원 대신 직원 배달 작업자와 같이, 직원 배송 업체를 선호하는 배달 배송 업체에 대한 규칙을 포함할 수 있다. 즉, 직원 배송 업체가 있는 지역의 풀필먼트 센터가 직원 배송 업체가 없고 제3자 배송 업체와 계약해야 하는 풀필먼트 센터보다 선호된다. 또한, 주문 할당 규칙은 예상 배달을 포함할 수 있다. 과거 트랜드와 제품 및 각 풀필먼트 센터의 연관성에 기초하여, 할당 규칙은 잠정적인 배달을 추정하고 배달 날짜가 더 짧은 풀필먼트 센터를 선호할 수 있다. 규칙은 또한 직원의 가용성 또는 역량이 높은 풀필먼트 센터를 선호하는 직원 할당 규칙을 포함할 수 있다. 더욱이 규칙은 풀필먼트 센터로의 소포의 인바운드 날짜에 대한 고려 사항도 포함할 수 있다. 이 규칙에 따라 시스템은 배달 확실성을 높이기 위해 패킷을 먼저 수신했을 풀필먼트 센터를 선호할 수 있다. 마지막으로, 규칙은 또한 소포 중량에 기초하여 선호도를 포함할 수 있다. 일부 풀필먼트 센터는 무겁거나 큰 소포를 처리하는데 더 나은 장비를 갖출 수 있으며 더 무거운 소포를 선호할 수 있다.
할당 규칙을 고려하여, MDR 시스템(320)은 단계 1512에서 계산된 우선 순위에 기초하여 풀필먼트 센터의 순위를 매길 수 있다. 예를 들어, 지역의 모든 풀필먼트 센터는 우선 순위 점수가 할당될 수 있고 풀필먼트 센터는 우선 순위 점수에 기초하여 순위가 매겨질 수 있다.
단계 1514에서, MDR 시스템(320)은 최상위 풀필먼트 센터가 유사한 우선 순위를 갖는지 여부를 결정할 수 있다. 예를 들어, MDR 시스템(320)은 풀필먼트 센터의 우선 순위 점수가 임계 값 내에 있는지 여부를 결정할 수 있다. 최상위 풀필먼트 센터가 유사한 우선 순위를 갖지 않는 경우(단계 1514 : 아니오), MDR 시스템(320)은 단계 1516으로 계속하여 가장 높은 우선 순위를 가진 풀필먼트 센터를 식별할 수 있다. 그러나, 최상위 풀필먼트 센터가 유사한 우선 순위를 갖는 경우(단계 1514 : 예), MDR 시스템(320)은 단계 918로 계속 진행하여 최상위 풀필먼트 센터를 선택하기 위해 랜덤화 기능을 적용할 수 있다. 랜덤화 기능은 많이 필요한 계산 없이도 풀필먼트 센터 전체에 걸쳐 로드의 분포를 용이하게 할 수 있다.
단계 1520에서, MDR 시스템(320)은 박스 통합 할당 추정을 수행할 수 있다. 선택된 풀필먼트 센터와 함께, MDR 시스템(320)은, 배송에 이용될 박스의 수를 포함하여, 풀필먼트 센터로부터의 배송 비용을 결정할 수 있다. 비용을 최소화하고 효율성을 개선하기 위해, 단계 1520에서 MDR 시스템(320)은 단계 1502에서 수신된 제품의 잠정적인 주문에 대한 박스 또는 소포의 수를 줄이는 것을 시도하기 위해 박스 통합을 수행할 수 있다.
단계 1522에서, MDR 시스템(320)은 박스 통합으로 소포 또는 박스의 수가 감소했는지 여부를 결정할 수 있다. 소포의 수가 감소하지 않으면(단계 922 : 아니오), MDR 시스템(320)은 단계 1524로 계속하여 이전 할당을 유지할 수 있다. 그러나, 박스 통합 후에 소포의 수가 감소하면(단계 1522 : 예), MDR 시스템(320)은 단계 1526으로 계속하여 할당을 통합 할당으로 업데이트 할 수 있다.
단계 1528에서, MDR 시스템(320)은 자동 밸런싱 통합을 수행할 수 있다. 자동 밸런싱 고려 사항은 단계 1504에서 식별된 지역의 서로 다른 풀필먼트 센터에서 로드 밸런싱을 시도할 수 있다. 특정 센터의 과중한 부담을 방지하기 위한 목표로, MDR 시스템(320)은 서로 다른 풀필먼트 센터에서 리소스의 활용도를 개선하기 위한 시도를 하여 자동 밸런싱을 수행할 수 있다.
단계 1530에서, 자동 밸런싱 통합에 기초하여, MDR 시스템(320)은, 단계 1516 또는 1518에서, 할당된 풀필먼트 센터가 목표 활용도를 초과하는지 여부를 결정할 수 있다. MDR 시스템(320)이 풀필먼트 센터가 목표 활용도를 초과하지 않는다고 결정하면(단계 1530 : 아니오), MDR 시스템(320)은 단계 1532로 계속하여 이전 할당을 유지할 수 있다. 그러나, MDR 시스템(320)이 풀필먼트 센터가 목표 활용도보다 높다고 결정하면(단계 1530 : 예), MDR 시스템(320)은 단계 1536으로 계속해서 선택된 풀필먼트 센터를 변경하여 선택된 풀필먼트 센터에 대한 과중한 부담을 피할 수 있다. 프로세스(1500)의 일부 실시예에서, MDR 시스템(320)은 단계 1536 이후에 단계 1520으로 복귀하여 새로 선택된 풀필먼트 센터에 대한 박스 및 자동 밸런싱 통합을 재실행 할 수 있다.
단계 1534에서, MDR 시스템(320)은 상태 테이블을 채우기 위해 선택된 풀필먼트 센터 및 대응하는 추정 시간을 단계 1502의 요청자 및/또는, MDR 데이터베이스(325)와 같은, 데이터베이스로 전송할 수 있다. 일부 실시예에서, PDD 또는 예상 배달 시간은 선택된 풀필먼트 센터에 대해 미리 생성될 수 있다. 예를 들어, PDD는 풀필먼트 센터와 연관된 배달 날짜 추정치, 주문 우선 순위, 제품의 인바운드 날짜, 배달을 위한 우편 번호 또는 제품과 연관련된 수량에 기초하여 미리 선택 될 수 있다.
도 16은 개시된 실시예에 따른, 다중 도메인 네트워크에서의 주문에 대한 예시적인 상태 결정 프로세스(1600)를 설명하는 상태 머신 다이어그램이다. 일부 실시예에서, 시스템 300)의 요소는 프로세스(1600)를 수행할 수 있다. 예를 들어, 아래의 단계 설명에 개시되는 바와 같이, MDR 시스템(320)은 프로세스(1600)를 수행할 수 있다. 대안적으로, 또는 추가적으로, 로컬 도메인(360) 및/또는 제3자 도메인(365)은 프로세스(1600), 또는 프로세스(1600)의 일부를, 수행할 수 있다. 또한, 다른 실시예에서 시스템(100), 또는 시스템(100)의 일부는, 프로세스(1500)를 수행할 수 있다. 예를 들어, SAT 시스템(101), FC Auth(123) 및/또는 FMG(115)(도 1a)는 프로세스(1500)를 수행할 수 있다.
도 16은 MDR 시스템(320)에 의해 모니터링 되고 있는 주문에 대한 잠재적 상태를 보여준다. 주문이 상태(1602)에서 수신되면, MDR 시스템(320)은 주문에 대한 ID를 생성하는 벤더(예를 들어, 제3자 도메인(365))에 주문을 라우팅 할 수 있다. 일부 실시예에서, 제3자 도메인(365)의 벤더는 상태 1604에서 order_numberkey가 됨에 대한 주문 키 및 새로운 상태를 생성할 수 있다. 주문 키로 상태 변수가 생성될 수 있고 상태(1606)에서 Order_Sent_To_Warehouse의 상태가 할당될 수 있다. 동시에, MDR 시스템(320), 할당된 벤더 또는 할당된 풀필먼트 센터는 상태(1610)에서 주문 상태에 추가되는 PDD를 요청할 수 있다.
도 16에 도시된 바와 같이, PDD가 주문에 대해 결정되면(예를 들어, 프로세스(1500)에 따라), 주문 상태는 2개의 서로 다른 경로를 따를 수 있다. 주문이 배송되고 업데이트 요청이 수신되면, 주문 상태는 shipped_event 상태(1612)로 업데이트되고 주문의 상태가 order_shipped 상태(1614)로 수정될 수 있다. 하지만 업데이트 요청이 수신되지 않은 경우 종료 시간 필드가 널이거나 시스템이 누락된 PDD(예를 들어, 현재 시간이 더 크고 예상 종료 시간)를 결정하면, 주문 상태는 order_missed _PDD 상태(1618)로 수정될 수 있다.
도 17은 개시된 실시예에 따른, 관리자 네트워크를 통해 전송되는 경보를 보여주는 그래픽 사용자 인터페이스(GUI)(1700)이다. GUI(1700)는 MDR 시스템(320)에 의해 호스팅 되고 클라이언트 디바이스(350)(도 3)에 디스플레이 될 수 있다. GUI(1700)는, 모니터링 엔진에 의해 표시된 상태 카테고리에 대응할 수 있는, 헤더(1702)를 보여준다. GUI(1700)는 또한 리포트 된 요소(1704(a)-(z))의 테이블을 포함할 수 있다. 테이블은 리포트 된 요소(1704) 각각을 주문 번호(1710), 현재 상태(1712), 시작 날짜(1714), 예상 종료 날짜(0716), 및 종료 시간(1718)과 연관시킨다. 일부 실시예에서, 도 17의 테이블은 사용자가 특정 아이템을 필터링, 정렬, 또는 검색하도록 허용할 수 있다. GUI(1700)는 또한 액션 버튼(1720)을 포함할 수 있으며, 이는 사용자가 GUI(1700)에 디스플레이 된 경고를 응답하거나 전달할 수 있게 한다.
본 개시의 다른 양상은, 실행될 때, 하나 이상의 프로세서로 하여금, 전술된 바와 같이, 방법을 수행하게하는 명령을 저장하는 비 일시적 컴퓨터 판독 가능한 매체에 관한 것이다. 컴퓨터 판독 가능한 매체는 휘발성 또는 비 휘발성, 자기, 반도체, 테이프, 광학, 착탈식, 비 착탈식, 또는 다른 유형의 컴퓨터 판독 가능한 매체 또는 컴퓨터 판독 가능한 저장 디바이스를 포함할 수 있다. 예를 들어, 컴퓨터 판독 가능한 매체는, 개시된 바와 같이, 컴퓨터 명령이 저장된 저장 유닛 또는 메모리 모듈일 수 있다. 일부 실시예에서, 컴퓨터 판독 가능한 매체는 컴퓨터 명령이 저장된 디스크 또는 플래시 드라이브 일 수 있다.
개시된 시스템 및 관련 방법에 대해 다양한 수정 및 변경이 이루어질 수 있다는 것은 당업자에게 명백 할 것이다. 다른 실시예는 개시된 시스템 및 관련 방법의 명세서 및 실행을 고려함으로써 당업자에게 명백 할 것이다. 명세서 및 실시예는 단지 예시적인 것으로 간주되며, 진정한 범위는 다음의 청구범위 및 그 균등물에 의해 표시된다.
본 개시는 그 특정 실시예를 참조하여 도시되고 설명되었지만, 본 개시는 다른 환경에서, 변경없이, 실시될 수 있음을 이해할 것이다. 전술한 설명은 예시의 목적으로 제시되었다. 그것은 개시된 정확한 형태나 실시예에 대해 총망라된 것이 아니며 이것으로 한정되는 것은 아니다. 개시된 실시예의 설명 및 실시를 고려하는 것으로부터 변경 및 조정이 통상의 기술자에게 명백할 것이다. 추가적으로, 비록 개시된 실시예의 형태가 메모리에 저장되는 것으로서 설명되었지만, 통상의 기술자는 이들 형태가 2차 저장 디바이스, 예를 들면, 하드디스크나 CD ROM, 또는 다른 형태의 RAM이나 ROM, USB 매체, DVD, 블루레이, 또는 다른 광 드라이브 매체와 같이, 다른 형태의 컴퓨터 판독 가능한 매체에 저장될 수도 있는 것을 이해할 것이다.
상술한 설명 및 개시된 방법에 기초한 컴퓨터 프로그램은 숙련된 개발자의 기술 내에 있다. 여러 프로그램 혹은 프로그램 모듈은 통상의 기술자에게 알려진 어느 기술을 이용하여 생성되거나, 또는 기존의 소프트웨어와 연결하여 설계될 수 있다. 예를 들면, 프로그램 섹션 혹은 프로그램 모듈은 닷넷 프레임워크, 닷넷 컴팩트 프레임워크(및 비주얼 베이식, C 등과 같은, 관련 언어), 자바, C++, 오브젝티브 C, HTML, HTML/AJAX 조합, XML, 또는 자바 애플릿이 포함된 HTML 내에서 혹은 그것들에 의해서 설계될 수 있다.
게다가, 여기에서는 예시적인 실시예가 설명되었지만, 본 개시에 기초하여 통상의 기술자가 이해할 수 있는 바와 같이, 일부 또는 모든 실시예의 범위는 동등한 요소, 변경, 생략, 조합(예로써, 여러 실시예에 걸치는 형태의 조합), 조정 및/또는 수정을 가질 수 있다. 청구범위 내의 제한 사항은 그 청구범위 내에 적용된 언어에 기초하여 폭넓게 이해되도록 하는 것이며, 응용의 수행 동안 혹은 본 명세서 내에 설명된 예시로 한정되는 것은 아니다. 그 예시는 비배타적으로 해석되도록 하기 위한 것이다. 추가로, 개시된 방법의 스텝은 어떤 다른 방법으로 변경되거나, 스텝을 재배열 및/또는 스텝을 삽입하거나 삭제하는 것을 포함할 수 있다. 그러므로, 설명 및 예시는 오직 예시적으로 고려되는 것이며, 진정한 범위 및 기술 사상은 다음의 청구범위 및 그 동등한 전체 범위에 의해 나타내지는 것으로 의도된다.
따라서, 전술한 설명은 단지 예시의 목적으로 제시되었다. 이는 완전하지 않으며 개시된 정확한 형태 또는 실시예로 제한되지 않는다. 개시된 실시예의 명세서 및 실행을 고려하면 수정 및 개조가 당업자에게 명백할 것이다.
청구범위는 청구범위에 사용된 언어에 기초하여 광범위하게 해석되어야 하며, 본 명세서에 기술된 예에 제한되지 않으며, 이러한 예는 비 배타적인 것으로 해석되어야 한다. 또한, 개시된 방법의 단계는 단계 재정렬 및/또는 단계 삽입 또는 삭제를 포함하여 임의의 방식으로 수정될 수 있다.

Claims (20)

  1. 적어도 하나의 프로세서; 및
    실행될 때 상기 적어도 하나의 프로세서가 동작을 수행하도록 구성하는 명령을 포함하는 적어도 하나의 메모리 디바이스를 포함하고,
    상기 동작은
    제1 도메인 및 제2 도메인과의 연결을 설정하고;
    모니터링 동작을 개시하기 위해 상기 제1 도메인으로부터 제1 요청을 수신하고 - 상기 제1 요청은 생성 요청을 포함함 -;
    제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고 - 상기 상태 테이블은 ID 필드, 예상 종료 필드 및 상태 필드를 포함함 -;
    상기 모니터링 동작을 업데이트하기 위해 상기 제2 도메인으로부터 제2 요청을 수신하고 - 상기 제2 요청은 업데이트 상태 요청을 포함함-;
    상기 제2 요청을 수신하는 것에 응답하여, 상기 상태 필드를 수정하여 상기 상태 테이블의 상기 새로운 엔트리를 업데이트하고;
    모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 - 상기 제3 요청은 리포트 요청 및 카테고리 상태를 포함하고, 상기 모니터링 엔진은 주기적으로 상기 제3 요청을 생성하도록 구성됨 -; 그리고
    상기 상태 필드가 상기 카테고리 상태와 일치하는 상기 상태 테이블의 엔트리를 포함하는 경보를 생성하는 것을 포함하는, 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 시스템.
  2. 청구항 1에 있어서,
    상기 제1 도메인은 주문 접수 도메인을 포함하고;
    상기 제2 도메인은 주문 배송 도메인을 포함하고;
    상기 제2 도메인과의 연결을 설정하는 것은 배송 업데이트 수신기에서 하나 이상의 포트를 개방하는 것을 포함하고; 그리고
    상기 카테고리 상태는 누락된 PDD 또는 널 종료 시간 중 적어도 하나를 포함하는, 시스템.
  3. 청구항 1에 있어서,
    상기 제1 요청은 주문 키를 포함하는 제1 REST API 호출을 포함하고 - 상기 주문 키는 아이템 ID 및 벤더 ID를 인코딩함 -; 그리고
    상기 제2 요청은 배송 정보를 포함하는 제2 REST API 호출을 포함하는, 시스템.
  4. 청구항 3에 있어서,
    상기 새로운 엔트리를 생성하는 것은 상기 벤더 ID, 현재 시간 및 시작 시간에 기초하여 상기 예상 완료 필드의 값을 추정하는 것을 포함하는, 시스템.
  5. 청구항 1에 있어서,
    상기 제1 도메인과 상기 제2 도메인의 연결을 설정하는 것은,
    상기 제1 도메인 및 상기 제2 도메인과 연관된 구성 템플릿을 자동으로 디스커버링 하고;
    새로운 주문이 수신되거나 주문이 풀필먼트 센터로 전송될 때 생성 요청을 생성하도록, 상기 제1 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제1 도메인을 구성하고; 그리고
    아이템이 배송될 때 업데이트 요청을 생성하기 위해, 상기 제2 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제2 도메인을 구성하는 것을, 포함하는 자동화된 디스커버리 동작을 수행하는 것을 포함하는 시스템.
  6. 청구항 5에 있어서,
    상기 동작은
    자동화된 디스커버리 동작을 수행하여 제3 도메인 및 제4 도메인과 연결을 설정 - 상기 제3 도메인은 재고 도메인이고, 상기 제4 도메인은 제3자 도메인임 - 하는 것을 더 포함하는, 시스템.
  7. 청구항 1에 있어서,
    상기 모니터링 엔진은 적어도 하루에 한 번 주기적으로 상기 제3 요청을 생성하도록 구성 가능하고; 그리고
    상기 경보를 생성하는 것은 관리자 네트워크에 이메일 메시지를 브로드 캐스팅하는 것을 포함하는, 시스템.
  8. 청구항 1에 있어서,
    상기 상태 테이블은 현재 상태 필드, 예상 상태 필드 및 시작 시간 필드를 더 포함하는, 시스템.
  9. 청구항 1에 있어서,
    상기 제1 도메인은 주문 접수 도메인을 포함하고;
    상기 제2 도메인은 재고 도메인 또는 구매 도메인 중 적어도 하나를 포함하는, 시스템.
  10. 청구항 1에 있어서,
    상기 상태 필드의 값은, 널 값, 창고로 전송된 주문 값, 배송된 주문 값, 누락된 PDD 값 또는 완료된 값을 포함하는 그룹으로부터 선택되고:
    상기 동작은 예상 종료 필드를 현재 시간과 비교하는 것에 기초하여 상기 누락된 PDD값을 상기 상태 테이블의 엔트리에 할당하는 것을 더 포함하고;
    상기 모니터링 동작은 상기 상태 필드의 상기 값이 상기 널 값 또는 상기 누락된 PDD 값 중 적어도 하나 인 상기 상태 테이블의 엔트리를 식별하고; 그리고
    상기 모니터링 동작은 자동화 서버를 통해 수행되는, 시스템.
  11. 제1 도메인 및 제2 도메인과의 연결을 설정하고;
    모니터링 동작을 개시하기 위해 상기 제1 도메인으로부터 제1 요청을 수신하고 - 상기 제1 요청은 생성 요청을 포함함 -;
    제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고 - 상기 상태 테이블은 ID 필드, 예상 종료 필드 및 상태 필드를 포함함 -;
    상기 모니터링 동작을 업데이트하기 위해 상기 제2 도메인으로부터 제2 요청을 수신하고 - 상기 제2 요청은 업데이트 상태 요청을 포함함-;
    상기 제2 요청을 수신하는 것에 응답하여, 상기 상태 필드를 수정하여 상기 상태 테이블의 상기 새로운 엔트리를 업데이트하고;
    모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 - 상기 제3 요청은 리포트 요청 및 카테고리 상태를 포함하고, 상기 모니터링 엔진은 주기적으로 상기 제3 요청을 생성하도록 구성됨 -; 그리고
    상기 상태 필드가 상기 카테고리 상태와 일치하는 상기 상태 테이블의 엔트리를 포함하는 경보를 생성하는 것을 포함하는, 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링을 위한 컴퓨터-구현 방법.
  12. 청구항 11에 있어서,
    상기 제1 도메인은 주문 접수 도메인을 포함하고;
    상기 제2 도메인은 주문 배송 도메인을 포함하고;
    상기 제2 도메인과의 연결을 설정하는 것은 배송 업데이트 수신기에서 하나 이상의 포트를 개방하는 것을 포함하고; 그리고
    상기 카테고리 상태는 누락된 PDD 또는 널 종료 시간 중 적어도 하나를 포함하는, 방법.
  13. 청구항 11에 있어서,
    상기 제1 요청은 주문 키를 포함하는 제1 REST API 호출을 포함하고 - 상기 주문 키는 아이템 ID 및 벤더 ID를 인코딩함 -; 그리고
    상기 제2 요청은 배송 정보를 포함하는 제2 REST API 호출을 포함하는, 방법.
  14. 청구항 11에 있어서,
    상기 제1 도메인과 상기 제2 도메인의 연결을 설정하는 것은,
    상기 제1 도메인 및 상기 제2 도메인과 연관된 구성 템플릿을 자동으로 디스커버링 하고;
    새로운 주문이 수신되거나 주문이 풀필먼트 센터로 전송될 때 생성 요청을 생성하도록, 상기 제1 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제1 도메인을 구성하고; 그리고
    아이템이 배송될 때 업데이트 요청을 생성하기 위해, 상기 제2 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제2 도메인을 구성하는 것을, 포함하는 자동화된 디스커버리 동작을 수행하는 것을 포함하는 방법.
  15. 청구항 14에 있어서,
    상기 동작은
    자동화된 디스커버리 동작을 수행하여 제3 도메인 및 제4 도메인과 연결을 설정 - 상기 제3 도메인은 재고 도메인이고, 상기 제4 도메인은 제3자 도메인임 - 하는 것을 더 포함하는, 방법.
  16. 청구항 11에 있어서,
    상기 모니터링 엔진을 구성하는 것은 적어도 하루에 한 번 상기 제3 요청을 생성하는 것이고; 그리고
    상기 경보를 생성하는 것은 관리자 네트워크에 이메일 메시지를 브로드 캐스팅하는 것을 포함하는, 방법.
  17. 청구항 11에 있어서,
    상기 상태 테이블은 현재 상태 필드, 예상 상태 필드 및 시작 시간 필드를 더 포함하는, 방법.
  18. 청구항 11에 있어서,
    상기 제1 도메인은 주문 접수 도메인을 포함하고;
    상기 제2 도메인은 재고 도메인 또는 구매 도메인 중 적어도 하나를 포함하는, 방법.
  19. 청구항 11에 있어서,
    상기 상태 필드의 값은, 널 값, 창고로 전송된 주문 값, 배송된 주문 값, 누락된 PDD 값 또는 완료된 값을 포함하는 그룹으로부터 선택되고:
    상기 동작은 예상 종료 필드를 현재 시간과 비교하는 것에 기초하여 상기 누락된 PDD값을 상기 상태 테이블의 엔트리에 할당하는 것을 더 포함하고;
    상기 모니터링 동작은 상기 상태 필드의 상기 값이 상기 널 값 또는 상기 누락된 PDD 값 중 적어도 하나 인 상기 상태 테이블의 엔트리를 식별하고; 그리고
    상기 모니터링 동작은 자동화 서버를 통해 수행되는, 방법.
  20. 하나 이상의 프로세서; 및
    실행될 때 상기 하나 이상의 프로세서가:
    제1 도메인 및 제2 도메인과 연관된 구성 템플릿을 자동으로 디스커버링 하고;
    새로운 주문이 수신되거나 주문이 풀필먼트 센터로 전송될 때 생성 요청을 생성하도록, 상기 제1 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제1 도메인을 구성하고; 그리고
    아이템이 배송될 때 업데이트 요청을 생성하기 위해, 상기 제2 도메인과 연관된 하나 이상의 웹 API를 통해, 상기 제2 도메인을 구성하는 것을:
    포함하는 자동화된 디스커버리 동작을 수행하여 상기 제1 도메인 및 상기 제2 도메인과의 연결을 설정하고;
    모니터링 동작을 개시하기 위해 상기 제1 도메인으로부터 제1 요청을 수신하고 - 상기 제1 요청은 주문 키를 포함하는 제1 REST API 호출을 포함하고, 상기 주문 키는 아이템 ID 및 벤더 ID를 인코딩함 -;
    제1 데이터베이스에 저장된 상태 테이블에 새로운 엔트리를 생성하고 - 상기 상태 테이블은 ID 필드, 예상 종료 필드 및 상태 필드를 포함함 -;
    상기 모니터링 동작을 업데이트하기 위해 상기 제2 도메인으로부터 제2 요청을 수신하고 - 상기 제2 요청은 배송 정보를 포함하는 제2 REST API 호출을 포함함 -;
    상기 제2 요청을 수신하는 것에 응답하여, 상기 상태 필드를 수정하여 상기 상태 테이블의 상기 새로운 엔트리를 업데이트하고;
    모니터링 엔진으로부터 제3 요청을 수신하는 것에 응답하여 모니터링 동작을 적용하고 - 상기 제3 요청은 리포트 요청 및 카테고리 상태를 포함하고, 상기 모니터링 엔진은 적어도 하루에 한 번 상기 제3 요청을 생성하도록 구성되고, 상기 모니터링 동작은 자동화된 서버를 통해 수행됨 -;
    상기 상태 필드의 값이 널 또는 누락된 PDD 중 적어도 하나 인 상기 상태 테이블의 엔트리를 포함하는 관리자 네트워크에서 경고 이메일을 브로드 캐스팅,
    하도록 구성하는 명령을 포함하는 하나 이상의 메모리 디바이스를 포함하는 장치.
KR1020217020358A 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링 KR102549317B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020237021497A KR20230101937A (ko) 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/070,573 2020-10-14
US17/070,573 US11062253B1 (en) 2020-10-14 2020-10-14 Centralized status monitoring in a multidomain network
PCT/IB2020/059807 WO2022079483A1 (en) 2020-10-14 2020-10-19 Centralized status monitoring in a multidomain network

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020237021497A Division KR20230101937A (ko) 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링

Publications (2)

Publication Number Publication Date
KR20220051131A true KR20220051131A (ko) 2022-04-26
KR102549317B1 KR102549317B1 (ko) 2023-06-30

Family

ID=76764536

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020217020358A KR102549317B1 (ko) 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링
KR1020237021497A KR20230101937A (ko) 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020237021497A KR20230101937A (ko) 2020-10-14 2020-10-19 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링

Country Status (4)

Country Link
US (2) US11062253B1 (ko)
KR (2) KR102549317B1 (ko)
TW (2) TW202248918A (ko)
WO (1) WO2022079483A1 (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11438213B1 (en) * 2021-04-27 2022-09-06 Cox Communications, Inc. Enhanced management of network outages
US11265358B1 (en) * 2021-06-22 2022-03-01 Cabin Management Solutions, Llc Audio video over internet protocol (AVoIP) communication system
TWI801324B (zh) * 2022-11-15 2023-05-01 國立虎尾科技大學 冷凍設備遠端故障診斷系統及其方法
TWI828506B (zh) * 2023-01-03 2024-01-01 中華電信股份有限公司 安全基準評估系統及其方法
CN116915507B (zh) * 2023-09-12 2023-12-05 奇安星城网络安全运营服务(长沙)有限公司 基于安全信号匹配的计算机网络安全分析系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8473316B1 (en) * 2010-06-04 2013-06-25 Amazon Technologies, Inc. System and method for order processing state management
US20150371316A1 (en) * 2013-07-02 2015-12-24 Buzz Apps, Inc. System and a Method for Automatically Detecting and Processing Physical Events Indicative of Status of an Order and Notifying Customers of the Same

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8271336B2 (en) * 1999-11-22 2012-09-18 Accenture Global Services Gmbh Increased visibility during order management in a network-based supply chain environment
AU2002242036B2 (en) * 2001-02-02 2008-01-24 Opentv, Inc. Service platform suite management system
US7013289B2 (en) * 2001-02-21 2006-03-14 Michel Horn Global electronic commerce system
US7444298B2 (en) * 2001-08-28 2008-10-28 United Parcel Service Of America, Inc. Order and payment visibility process
US7565402B2 (en) * 2002-01-05 2009-07-21 Eric Schneider Sitemap access method, product, and apparatus
EP2204949B1 (en) 2005-11-11 2017-07-19 Accenture Global Services Limited End-to-end test and diagnostic manager as well as corresponding system and method
US9846902B2 (en) * 2011-07-19 2017-12-19 Slice Technologies, Inc. Augmented aggregation of emailed product order and shipping information
EP2767110A4 (en) 2011-10-12 2015-01-28 C Sam Inc PLATFORM FOR MULTI-STAGE SECURE MOBILE TRANSACTIONS
US20130159144A1 (en) * 2011-12-14 2013-06-20 Ebay Inc. System and method for providing alternative fulfillment for a buyer's unfulfillable order
US9298631B2 (en) * 2012-06-15 2016-03-29 International Business Machines Corporation Managing transactional and non-transactional store observability
US20150039702A1 (en) 2013-08-05 2015-02-05 NextPlane, Inc. System and method for monitoring a hub-based system federating disparate unified communications systems
TWI539404B (zh) * 2014-11-03 2016-06-21 Chunghwa Telecom Co Ltd Network service reservation management system
CN104836753B (zh) 2015-03-27 2018-10-02 清华大学 Sdn数据平面带状态交换设备、系统及转发处理方法
US10607042B1 (en) * 2019-02-12 2020-03-31 Live Objects, Inc. Dynamically trained models of named entity recognition over unstructured data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8473316B1 (en) * 2010-06-04 2013-06-25 Amazon Technologies, Inc. System and method for order processing state management
US20150371316A1 (en) * 2013-07-02 2015-12-24 Buzz Apps, Inc. System and a Method for Automatically Detecting and Processing Physical Events Indicative of Status of an Order and Notifying Customers of the Same

Also Published As

Publication number Publication date
US11062253B1 (en) 2021-07-13
US11681972B2 (en) 2023-06-20
TW202248918A (zh) 2022-12-16
WO2022079483A1 (en) 2022-04-21
KR102549317B1 (ko) 2023-06-30
TWI777532B (zh) 2022-09-11
TW202215319A (zh) 2022-04-16
KR20230101937A (ko) 2023-07-06
US20220114535A1 (en) 2022-04-14

Similar Documents

Publication Publication Date Title
KR102373372B1 (ko) 적응형 배달 스케줄링용 그래픽 유저 인터페이스를 생성하기 위한 시스템 및 방법
KR102549317B1 (ko) 다중 도메인 네트워크에서 중앙 집중식 상태 모니터링
TWI769538B (zh) 顯示交付日期估算的系統及方法以及電腦可讀取媒體
KR102408794B1 (ko) 하이퍼미디어 요소들을 갖는 동적 웹사이트들을 생성하기 위한 시스템들 및 방법들
KR102445640B1 (ko) 아웃바운드 예측을 위한 시스템 및 방법
KR20210035014A (ko) 비용 최적화된 구성을 생성하기 위한 패키지 구성의 시뮬레이션을 위한 시스템 및 방법
KR20220051129A (ko) 비동기적으로 큐에 더해진 요청의 오류를 검출하는 시스템 및 방법
KR20220047957A (ko) 인바운드 스토우 모델을 이용한 아웃바운드 예측을 위한 시스템 및 방법
KR20210109499A (ko) 데이터의 동적 집계와 데이터 손실의 최소화를 위한 시스템 및 방법
KR20220061061A (ko) 풀필먼트 센터 우선순위 값에 기초한 아웃바운드 예측을 위한 시스템 및 방법
KR102451184B1 (ko) 가상 번들의 동적 밸런싱을 위한 시스템 및 방법
KR20210033869A (ko) 응답적이고 자동 예측적인 패키징 획득을 위한 시스템 및 방법
KR20210033866A (ko) 우편 번호 매핑에 기초하여 아웃바운드를 예측하기 위한 시스템 및 방법
KR102402074B1 (ko) 이벤트 저장 관리를 위한 시스템 및 방법

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
A107 Divisional application of patent
GRNT Written decision to grant