KR20210038524A

KR20210038524A - 애플리케이션 프로그래밍 인터페이스 정보를 관리하기 위한 시스템 및 방법

Info

Publication number: KR20210038524A
Application number: KR1020210041282A
Authority: KR
Inventors: 박영진; 윤용현; 양원석
Original assignee: 쿠팡 주식회사
Priority date: 2019-03-11
Filing date: 2021-03-30
Publication date: 2021-04-07
Also published as: US20200293384A1; PH12020551788A1; AU2020238942A1; KR20200108753A; US10956233B2; SG11202011424QA; US10467062B1; CN110968626A; AU2020238942B2; WO2020183371A1; KR20220018537A; TWI743699B; KR102359069B1; CN110968626B; KR102236318B1; US11755386B2; JP6971404B2; TW202046092A; JP2021513133A; US20210240549A1

Abstract

API 정보를 관리하기 위한 컴퓨터화된 시스템 및 방법에 관한 것이다. 예시적인 방법은 제1 컴퓨터 시스템과 연관된 사용자 디바이스로부터 입력을 수신하는 단계―입력은 제2 컴퓨터 시스템의 아이덴티티를 포함하지 않음―를 포함한다. 방법은 입력에 기초하여 제2 컴퓨터 시스템의 API인 타겟 API를 결정하는 단계를 포함한다. 방법은 또한 사용자 디바이스의 사용자가 타겟 API에 액세스할 수 있는지를 판단하는 단계를 포함한다. 방법은 사용자가 타겟 API에 액세스할 수 있다고 판단하면, API 데이터베이스로부터 타겟 API의 문서를 검색하는 단계를 포함한다. 방법은 사용자 디바이스에 검색된 문서를 제공하는 단계를 포함한다.

Description

애플리케이션 프로그래밍 인터페이스 정보를 관리하기 위한 시스템 및 방법{SYSTEMS AND METHODS FOR MANAGING APPLICATION PROGRAMMING INTERFACE INFORMATION}

본 개시는 전반적으로 애플리케이션 프로그래밍 인터페이스 정보를 관리하기 위한 컴퓨터화된 시스템들 및 방법들에 관한 것이다. 특히, 본 개시의 실시예들은 데이터베이스에 저장된 컴퓨터 시스템들의 API 정보를 관리하고, 컴퓨터 시스템의 사용자가 또 다른 컴퓨터 시스템의 API의 문서를 얻을 수 있게 하는 독창적 및 비통상적인 시스템들에 관한 것이다.

API는 소프트웨어 애플리케이션을 구축하기 위한 루틴, 프로토콜, 및 툴의 집합이다. 양호한 API는 모든 구축 블록들을 제공함으로써 프로그램을 개발하는 것을 용이하게 한다. 프로그래머는 블록들을 함께 결합시킨다. 많은 운영 환경들이 프로그래머가 운영 환경에 따라서 애플리케이션을 작성할 수 있도록 API를 제공한다. API는 통상적으로 API를 사용하기 위한 명령을 제공하는 연관 문서를 갖는다.

문서는 다양한 형태로 존재할 수 있다. 과거에는, 문서에 대한 가장 일반적인 형태는 바운디드(bounded), 하드-카피 매뉴얼(hard-copy manual)이었다. 이 매뉴얼은 일반적으로 수백 페이지의 상세한 정보를 포함하는 크고 부피가 큰 매뉴얼이었다. 이러한 매뉴얼로부터 정보를 찾아내고 검색하기 위해, 일반적으로 프로그래머는 엄청난 양의 관련없는 정보를 검색해야만 했다. 많은 상이한 사업 단위, 운영 환경, 컴퓨터 시스템 및 API를 갖는 대규모 조직에서, 이러한 매뉴얼은 프로그래머에게 이들이 찾는 정확한 API 및 이의 연관 문서를 검색하고 결정하는데 많은 시간과 노력을 요구할 것이다.

지금의 정보 기술 시대에, 이러한 많은 하드-카피 매뉴얼은 전자 버전으로 변환되어 데이터베이스에 배치되어 있다. 또한, 일부 새로운 문서는 특별히 인터넷 및 컴퓨터 시스템을 위해 설계된다. 상기 새로운 문서는 사용자-친화적이고 API에 적용가능한 프로그래밍 코드로 쉽게 변환될 수 있는 문서의 전자 버전을 생성하거나 생성을 도울 수 있는 문서 툴 및 인터페이스를 포함한다.

그러나 API의 문서의 전자 버전은 특정 기술적 문제를 극복하기에 충분하지 않을 수 있다. 많은 상이한 사업 단위, 운영 환경, 컴퓨터 시스템, 및 API를 갖는 대규모 조직에서, API 및 API의 문서의 양과 복잡성으로 인해 조직의 데이터베이스를 관리하기가 어려워졌다. 상이한 사업 단위 및 운영 환경에 있는 사용자는 다른 사업 단위 및 운영 환경의 API와의 상호작용을 시도할 수 있다. 개발자가 상호작용할 수 있는 모든 사업 단위, 운영 환경, 컴퓨터 시스템, 및 API의 아이덴티티(identity)를 알도록 요구하는 것은 비효율적이다. 상이한 컴퓨터 시스템 또는 하나의 컴퓨터 시스템의 서브시스템과 연관된 API에 대해 작업하는 개발자는 각각의 상이한 기능성에 대한 최적화된 선택으로서 상이한 코딩 언어를 사용할 필요가 있을 수 있다. 대규모 조직은 매우 빠르게 업데이트하는 그들의 컴퓨터 시스템 및 API를 가질 수 있으며, 이는 모든 API의 개발자가 적시에 변경사항을 따라잡고 충돌을 해결하는 것을 어렵고 번거롭게 한다. 문서의 간단한 전자 버전 또는 단순히 문서를 저장하는 시스템은 사용자에게 많은 부담을 덜어주거나 적시의 조정을 제공하지 않는다.

그러므로, 전자적 API 관리를 위한 개선된 방법들 및 시스템들이 필요하다.

본 개시의 일 양태는 API 정보를 관리하는 시스템에 관한 것이다. 시스템은 적어도 하나의 프로세서, 컴퓨터 시스템들의 API들과 연관된 데이터 및 문서를 저장하는 데이터베이스, 및 적어도 하나의 프로세서에 의해 실행될 때, 프로세서가 동작들을 수행하게 하는 명령들을 저장하는 적어도 하나의 메모리를 포함할 수 있다. 동작들은 제1 컴퓨터 시스템과 연관된 사용자 디바이스로부터 입력을 수신하는 동작―입력은 제2 컴퓨터 시스템의 아이덴티티(identity)를 포함하지 않음―을 포함할 수 있다. 또한, 동작들은 사용자의 허가 레벨(permission level)에 기초하여 사용자 디바이스의 사용자가 액세스할 수 없는 컴퓨터 시스템들과 연관된 API들을 배제하는 동작, 입력에 기초하여 제2 컴퓨터 시스템의 API인 타겟 API를 결정하는 동작, 및 사용자 디바이스의 사용자가 타겟 API에 액세스할 수 있는지를 판단하는 동작을 포함할 수 있다. 사용자가 타겟 API에 액세스를 할 수 있다고 판단되면, 시스템은 API 데이터베이스로부터 타겟 API의 문서를 검색하고, 타겟 API의 검색된 문서를 사용자 디바이스에 제공할 수 있다.

본 개시의 또 다른 양태는 API 데이터 및 문서를 관리하기 위한 방법에 관한 것이다. 방법은, 제1 컴퓨터 시스템과 연관된 사용자 디바이스로부터 입력을 수신하는 단계―입력은 제2 컴퓨터 시스템의 아이덴티티를 포함하지 않음―를 포함할 수 있다. 또한, 방법은 사용자의 허가 레벨에 기초하여 사용자 디바이스의 사용자가 액세스할 수 없는 컴퓨터 시스템들과 연관된 API들을 배제하는 단계, 입력에 기초하여 제2 컴퓨터 시스템의 API인 타겟 API를 결정하는 단계, 및 사용자 디바이스의 사용자가 타겟 API에 액세스할 수 있는지를 판단하는 단계를 포함할 수 있다. 방법은 사용자가 타겟 API에 액세스를 할 수 있다고 판단되면, API 데이터베이스로부터 타겟 API의 문서를 검색하는 단계 및 타겟 API의 검색된 문서를 사용자 디바이스에 제공하는 단계를 더 포함한다.

본 개시의 또 다른 양태는 API 정보를 관리하기 위한 시스템에 관한 것이다. 시스템은 적어도 하나의 프로세서, API와 연관된 데이터를 저장하는 데이터베이스로서, 각 API는 적어도 하나의 컴퓨터 시스템과 연관되며, 컴퓨터 시스템들 각각은 각각의 API를 통해 컴퓨터 시스템들 중 다른 컴퓨터 시스템들과 접속가능한, 데이터베이스, 및 적어도 하나의 프로세서에 의해 실행될 때, 프로세서가 동작들을 수행하게 하는 명령들을 저장하는 적어도 하나의 메모리를 포함할 수 있다. 동작들은, 제1 컴퓨터 시스템과 연관된 사용자 디바이스로부터 입력을 수신하는 동작―입력은 제2 컴퓨터 시스템의 아이덴티티를 포함하지 않음―, 사용자의 허가 레벨에 기초하여 사용자 디바이스의 사용자로 액세스할 수 없는 컴퓨터 시스템들과 연관된 API들을 배제하는 동작, 및 입력에 기초하여 제2 컴퓨터 시스템의 API인 타겟 API를 결정하는 동작을 포함할 수 있다. 동작들은, 사용자 디바이스의 사용자가 타겟 API에 액세스할 수 있는지를 판단하는 동작, 사용자가 타겟 API에 액세스를 할 수 있다고 판단되면, API 데이터베이스로부터 타겟 API의 문서를 검색하는 동작, 및 타겟 API의 검색된 문서를 사용자 디바이스에 제공하는 동작을 포함한다. 동작들은, 컴퓨터 시스템들 중 하나의 컴퓨터 시스템의 API를 API 데이터베이스 내에 등록하라는 요청을 수신하는 동작, API 데이터베이스 내에 API와 연관된 데이터를 저장하는 동작, 요청에 기초하여 API와 연관된 문서를 생성하고 문서를 데이터베이스 내에 저장하는 동작, API 데이터베이스 내에 저장된 API들 중 하나의 API의 데이터 또는 문서를 업데이트하라는 요청을 수신하는 동작을 더 포함한다. 동작들은 요청에 기초하여 API의 데이터 또는 문서를 업데이트하는 동작 및 요청에 응답하여, 컴퓨터 시스템들과 연관된 사용자 디바이스들에 통지를 전송하는 동작을 더 포함한다.

다른 시스템들, 방법들, 및 컴퓨터-판독가능한 매체들이 또한 본 명세서에서 논의된다.

도 1a는 개시된 실시예들에 따른, 배송, 운송, 및 물류 동작을 가능하게 하는 통신을 위한 컴퓨터화된 시스템을 포함하는, 시스템의 예시적인 실시예를 도시하는 개략적인 블록도이다.
도 1b는 개시된 실시예들에 따른, 상호작용 사용자 인터페이스 요소와 함께 검색 요청을 만족시키는 하나 이상의 검색 결과를 포함하는 샘플 검색 결과 페이지(Search Result Page)(SRP)를 도시한다.
도 1c는 개시된 실시예들에 따른, 제품 및 상호작용 사용자 인터페이스 요소와 함께 제품에 관한 정보를 포함하는 샘플 단일 디스플레이 페이지(Single Display Page)(SDP)를 도시한다.
도 1d는 개시된 실시예들에 따른, 상호작용 사용자 인터페이스 요소와 함께 가상 쇼핑 장바구니에 아이템을 포함하는 샘플 장바구니 페이지를 도시한다.
도 1e는 개시된 실시예들에 따른, 상호작용 사용자 인터페이스 요소와 함께 구매 및 배송에 관한 정보와 함께 가상 쇼핑 장바구니로부터의 아이템을 포함하는 샘플 주문 페이지(sample Order page)를 도시한다.
도 2는 개시된 실시예들에 따른, 개시된 컴퓨터화된 시스템을 사용하도록 구성된 예시적인 풀필먼트 센터의 개략도이다.
도 3은 개시된 실시예들에 따른, API 정보를 관리하기 위한 예시적인 시스템의 개략도를 도시한다.
도 4는 개시된 실시예들에 따른, 데이터베이스 내에 API를 등록하기 위한 프로세스를 도시한다.
도 5는 개시된 실시예들에 따른, 데이터베이스 내에서 API 정보를 업데이트하기 위한 프로세스를 도시한다.
도 6은 개시된 실시예들에 따른, 문서를 사용자 디바이스에 제공하는 예시적인 프로세스를 도시한다.
도 7은 개시된 실시예들에 따른, API 정보를 관리하기 위한 시스템의 예시적인 사용자 인터페이스를 도시한다.

이하의 상세한 설명은 첨부 도면을 참조한다. 가능하면, 동일한 참조 번호가 도면 및 이하의 설명에서 동일하거나 또는 유사한 부분을 참조하기 위해 사용된다. 몇몇 예시적인 실시예가 본 명세서에 설명되지만, 변형예, 적응예 및 다른 구현예가 가능하다. 예를 들어, 도면들에 도시된 구성 요소들 및 단계들에 대한 대체예, 추가예 또는 변형예가 이루어질 수 있으며, 본 명세서에서 설명된 예시적 방법들을 개시된 방법들에 대해 단계들을 대체, 재정렬, 제거 또는 추가함으로써 변형될 수 있다. 따라서 이하의 상세한 설명은 개시된 실시예들 및 예시들로 제한되지 않는다. 대신에, 본 발명의 적합한 범위는 첨부된 청구 범위에 의해 규정된다.

본 개시의 실시예들은 API 정보를 관리하도록 구성된 시스템들 및 방법들에 관한 것이다.

도 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 Detail 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), 할인 등에 대한 개선된 배달 옵션에 관한 정보를 포함할 수 있다. 외부 프론트 엔드 시스템(103)은(예를 들면, 네트워크를 통해) SRP를 요청 사용자 디바이스로 전송할 수 있다.

사용자 디바이스는 SRP에 나타낸 제품을 선택하기 위해, 예를 들면, 사용자 인터페이스를 클릭 또는 탭핑하거나, 다른 입력 디바이스를 사용하여 SRP로부터 제품을 선택할 수 있다. 사용자 디바이스는 선택된 제품에 관한 정보에 대한 요청을 만들어 내고 이를 외부 프론트 엔드 시스템(103)으로 전송할 수 있다. 이에 응답하여, 외부 프론트 엔드 시스템(103)은 선택된 제품에 관한 정보를 요청할 수 있다. 예를 들면, 정보는 각각의 SRP 상에 제품에 대해 제시된 것 이상의 추가 정보를 포함할 수 있다. 이는, 예를 들면, 유통 기한, 원산지, 무게, 크기, 패키지 내의 아이템 개수, 취급 지침, 또는 제품에 대한 다른 정보를 포함할 수 있다. 정보는 또한,(예를 들면, 이 제품 및 적어도 하나의 다른 제품을 구입한 고객의 빅 데이터 및/또는 기계 학습 분석에 기초한) 유사한 제품에 대한 추천, 자주 묻는 질문에 대한 답변, 고객의 후기, 제조 업체 정보, 사진 등을 포함할 수 있다.

외부 프론트 엔드 시스템(103)은 수신된 제품 정보에 기초하여 SDP(Single Detail Page)(예를 들면, 도 1c)를 준비할 수 있다. SDP는 또한, "지금 구매(Buy Now)" 버튼, "장바구니에 추가(Add to Cart)" 버튼, 수량 필드, 아이템 사진 등과 같은 다른 상호 작용 요소를 포함할 수 있다. SDP는 제품을 오퍼하는 판매자의 리스트를 포함할 수 있다. 이 리스트는 최저가로 제품을 판매하는 것으로 오퍼하는 판매자가 리스트의 최상단에 위치하도록, 각 판매자가 오퍼한 가격에 기초하여 순서가 정해질 수 있다. 이 리스트는 또한 최고 순위 판매자가 리스트의 최상단에 위치하도록, 판매자 순위에 기초하여 순서가 정해질 수 있다. 판매자 순위는 예를 들어, 약속된 PDD를 지켰는지에 대한 판매자의 과거 추적 기록을 포함하는 복수의 인자에 기초하여 만들어질 수 있다. 외부 프론트 엔드 시스템(103)은 (예를 들면, 네트워크를 통해) SDP를 요청 사용자 디바이스로 전달할 수 있다.

요청 사용자 디바이스는 제품 정보를 나열하는 SDP를 수신할 수 있다. SDP를 수신하면, 사용자 디바이스는 SDP와 상호 작용할 수 있다. 예를 들면, 요청 사용자 디바이스의 사용자는 SDP의 "장바구니에 담기(Place in Cart)" 버튼을 클릭하거나, 이와 상호 작용할 수 있다. 이렇게 하면 사용자와 연계된 쇼핑 장바구니에 제품이 추가된다. 사용자 디바이스는 제품을 쇼핑 장바구니에 추가하기 위해 외부 프론트 엔드 시스템(103)으로 이러한 요청을 전송할 수 있다.

외부 프론트 엔드 시스템(103)은 장바구니 페이지(예를 들면, 도 1d)를 생성할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 가상의 "쇼핑 장바구니(shopping cart)"에 추가한 제품을 나열한다. 사용자 디바이스는 SRP, SDP, 또는 다른 페이지의 아이콘을 클릭하거나, 상호 작용함으로써 장바구니 페이지를 요청할 수 있다. 일부 실시예에서, 장바구니 페이지는 사용자가 장바구니에 추가한 모든 제품 뿐 아니라 각 제품의 수량, 각 제품의 아이템당 가격, 관련 수량에 기초한 각 제품의 가격, PDD에 관한 정보, 배달 방법, 배송 비용, 쇼핑 장바구니의 제품을 수정(예를 들면, 수량의 삭제 또는 수정)하기 위한 사용자 인터페이스 요소, 다른 제품의 주문 또는 제품의 정기적인 배달 설정에 대한 옵션, 할부(interest payment) 설정에 대한 옵션, 구매를 진행하기 위한 사용자 인터페이스 요소 등과 같은 장바구니의 제품에 관한 정보를 나열할 수 있다. 사용자 디바이스의 사용자는 쇼핑 장바구니에 있는 제품의 구매를 시작하기 위해 사용자 인터페이스 요소(예를 들면, "지금 구매(Buy Now)"라고 적혀있는 버튼)를 클릭하거나, 이와 상호 작용할 수 있다. 그렇게 하면, 사용자 디바이스는 구매를 시작하기 위해 이러한 요청을 외부 프론트 엔드 시스템(103)으로 전송할 수 있다.

외부 프론트 엔드 시스템(103)은 구매를 시작하는 요청을 수신하는 것에 응답하여 주문 페이지(예를 들면, 도 1e)를 생성할 수 있다. 일부 실시예에서, 주문 페이지는 쇼핑 장바구니로부터의 아이템을 재나열하고, 결제 및 배송 정보의 입력을 요청한다. 예를 들면, 주문 페이지는 쇼핑 장바구니의 아이템 구매자에 관한 정보(예를 들면, 이름, 주소, 이메일 주소, 전화번호), 수령인에 관한 정보(예를 들면, 이름, 주소, 전화번호, 배달 정보), 배송 정보(예를 들면, 배달 및/또는 픽업 속도/방법), 결제 정보(예를 들면, 신용 카드, 은행 송금, 수표, 저장된 크레딧), 현금 영수증을 요청하는 사용자 인터페이스 요소(예를 들면, 세금 목적) 등을 요청하는 섹션을 포함할 수 있다. 외부 프론트 엔드 시스템(103)은 사용자 디바이스에 주문 페이지를 전송할 수 있다.

사용자 디바이스는 주문 페이지에 정보를 입력하고 외부 프론트 엔드 시스템(103)으로 정보를 전송하는 사용자 인터페이스 요소를 클릭하거나, 상호 작용할 수 있다. 그로부터, 외부 프론트 엔드 시스템(103)은 정보를 시스템(100) 내의 다른 시스템으로 전송하여 쇼핑 장바구니의 제품으로 신규 주문을 생성하고 처리할 수 있도록 한다.

일부 실시예에서, 외부 프론트 엔드 시스템(103)은 판매자가 주문과 관련된 정보를 통신 및 전송할 수 있도록 추가로 구성될 수 있다.

일부 실시예에서, 내부 프론트 엔드 시스템(105)은 내부 사용자(예를 들면, 시스템(100)을 소유, 운영 또는 임대하는 조직의 직원)가 시스템(100) 내의 하나 이상의 시스템과 상호작용할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 네트워크(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를 계산할 수 있다.

일부 실시예에서, FO 시스템(113)은 주기적으로(예를 들면, 시간별로) 각 제품에 대한 PDD를 결정하고, 검색하거나 다른 시스템(예를 들면, 외부 프론트 엔드 시스템(103), SAT 시스템(101), 배송 및 주문 트래킹 시스템(111))으로 전송하기 위해 이를 데이터베이스에 저장할 수 있다. 다른 실시예에서, FO 시스템(113)은 하나 이상의 시스템(예를 들면, 외부 프론트 엔드 시스템(103), SAT 시스템(101), 배송 및 주문 트래킹 시스템(111))으로부터 전자적 요청을 수신하고 요구에 따라 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)는 임의의 할당된 프로세스(예를 들면, 트럭에서 내리기, 픽업 구역에서 아이템을 픽업하기, 리빈 월 작업, 아이템 패킹하기), 사용자 식별자, 위치(예를 들면, 풀필먼트 센터(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)를 나타낸다. 풀필먼트 센터(200)는 주문시 고객에게 배송하기 위한 아이템을 저장하는 물리적 장소의 예시이다. 풀필먼트 센터(FC)(200)는 다수의 구역으로 분할될 수 있으며, 각각이 도 2에 도시된다. 일부 실시예에서, 이러한 "구역(zones)"은 아이템을 수령하고, 아이템을 저장하고, 아이템을 검색하고, 아이템을 배송하는 과정의 상이한 단계 사이의 가상 구분으로 생각될 수 있다. 따라서, "구역"이 도 2에 나타나 있으나, 일부 실시예에서, 구역의 다른 구분도 가능하고, 도 2의 구역은 생략, 복제, 또는 수정될 수 있다.

인바운드 구역(203)은 도 1a의 시스템(100)을 사용하여 제품을 판매하고자 하는 판매자로부터 아이템이 수신되는 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)과 관련된 바코드를 스캔할 수 있다. 그 다음 피커는 아이템을(예를 들면, 카트에 놓거나 운반함으로써) 픽업 구역(209)에 아이템을 가져갈 수 있다.

픽업 구역(209)은 아이템(208)이 저장 유닛(210)에 저장되는 FC(200)의 영역일 수 있다. 일부 실시예에서, 저장 유닛(210)은 물리적 선반, 책꽂이, 박스, 토트(tote), 냉장고, 냉동고, 저온 저장고 등 중 하나 이상을 포함할 수 있다. 일부 실시예에서, 픽업 구역(209)은 다수의 플로어로 편성될 수 있다. 일부 실시예에서, 작업자 또는 기계는, 예를 들면, 포크리프트, 엘리베이터, 컨베이어 벨트, 카트, 핸드트럭, 짐수레, 자동화된 로봇 또는 디바이스, 또는 수작업을 포함하는 다양한 방식으로 아이템을 픽업 구역(209)으로 운반할 수 있다. 예를 들면, 피커는 아이템(202A, 202B)을 드롭 구역(207)의 핸드트럭 또는 카트에 놓을 수 있으며, 아이템(202A, 202B)을 픽업 구역(209)으로 가져갈 수 있다.

피커는 저장 유닛(210) 상의 특정 공간과 같은 픽업 구역(209)의 특정 스팟에 아이템을 배치(또는 "적재(stow)")하라는 명령을 수신할 수 있다. 예를 들면, 피커는 모바일 디바이스(예를 들면, 디바이스(119B))를 사용하여 아이템(202A)을 스캔할 수 있다. 디바이스는, 예를 들면, 통로, 선반 및 위치를 나타내는 시스템을 사용하여, 아이템(202A)을 적재해야 하는 위치를 나타낼 수 있다. 그 다음 디바이스는 그 위치에 아이템(202A)을 적재하기 전에 피커가 그 위치에서 바코드를 스캔하도록 할 수 있다. 디바이스는 도 1a의 WMS(119)와 같은 컴퓨터 시스템에 아이템(202A)이 디바이스(119B)를 사용하는 사용자에 의해 그 위치에 적재되었음을 나타내는 데이터를(예를 들면, 무선 네트워크를 통해) 전송할 수 있다.

일단 사용자가 주문을 하면, 피커는 저장 유닛(210)으로부터 하나 이상의 아이템(208)을 검색하기 위해 디바이스(119B)에 명령을 수신할 수 있다. 피커는 아이템(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)에 의해 소유, 임대 또는 운행될 수 있다.

도 3은 개시된 실시예들에 따른, API 정보를 관리하기 위한 예시적인 시스템(예시적 시스템(300))의 개략도를 도시한다. 시스템(300)은 API 관리 시스템(310), API 접속 시스템(318), 컴퓨터 시스템(303), API(305), 데이터베이스(330), 및 네트워크(320)를 포함할 수 있다. 컴퓨터 시스템들의 API들은 네트워크(320)를 통해 서로 접속될 수 있다. 컴퓨터 시스템(303)은 하나 이상의 API들을 포함할 수 있다. 또한, 동일한 컴퓨터 시스템의 API들은 네트워크(320)를 통해 서로 접속될 수 있다. 또한, 하나의 컴퓨터 시스템과 연관된 사용자 디바이스 또는 사용자 디바이스의 사용자는 네트워크(320)를 통해 다른 컴퓨터 시스템의 API에 접속될 수 있다.

컴퓨터 시스템(303)은 시스템(100) 내의 시스템들 중 하나 이상을 포함하는 컴퓨터 시스템일 수 있다. 각각이 (예를 들어, 직접 또는 네트워크(320)를 통해) 서로 접속될 수 있는 다수의 컴퓨터 시스템들(303)이 있을 수 있다. 컴퓨터 시스템(303)은 서버, 워크스테이션, 데스크탑 컴퓨터, 모바일 디바이스, 또는 특수-목적 컴퓨팅 디바이스(special-purpose computing device)와 같은 하나 이상의 컴퓨팅 디바이스들을 포함할 수 있다. 또한, 컴퓨터 시스템(303)은 시스템(100) 내의 다양한 시스템들의 서브시스템의 일부일 수 있다. 예를 들어, 컴퓨터 시스템(303)은 각 제품에 대한 대응하는 PDD를 계산하는 FO 시스템(113)의 서브시스템일 수 있다.

API(305)는 컴퓨터 시스템(303)이 하나 이상의 API를 가질 수 있거나 각각이 자신의 API를 갖는 서브시스템들을 가질 수 있기 때문에 하나 이상의 API를 포함할 수 있다. 또한, API(305)는 하나 이상의 컴퓨터 시스템과 연관될 수 있다. API는 본 명세서에서 집합적으로 API로서 지칭되는 복수의 기능들 및 계층들을 포함할 수 있다. 일부 실시예들에서, API는 사용자 인터페이스 계층, API 기능 계층, 컴퓨터 시스템 계층, 공통 언어 계층, 또는 데이터베이스 계층과 같은 복수의 계층들을 포함할 수 있다. 계층들은 복수의 기능들을 포함할 수 있다. 예를 들어, API 기능 계층은, 애플리케이션 프로그래머, 고객, 감독자 등과 같은 API의 사용자에게 상이한 자원 또는 서비스를 제공하는 기능들의 그룹들을 포함할 수 있다. 사용자는 네트워크 플랫폼에 관련 및 접속된 기능들에 대해 작업할 수 있으며, 네트워크는 컴퓨터 시스템, 운영 환경, 또는 전체 조직 내 사설 네트워크이거나 외부 사용자와 연관된 공중 네트워크이다. 프로그래머 사용자는 네트워크 자원 및 다른 웹 서비스를 최대한 활용하는 컴퓨팅 시스템을 위한 웹 애플리케이션을, 이러한 네트워크 자원이 실제로 어떻게 작동하는지 또는 이용가능하게 되는지에 대한 복잡한 기술적 세부사항들을 이해할 필요없이, 생성할 수 있다.

API(305)를 사용하는 애플리케이션들은 복수의 프로그래밍 언어들로 작성될 수 있다. 예를 들어, 애플리케이션들은 .Net Framework, .NET Compact Framework(및 Visual Basic, C 등과 같은 관련 언어들), Java, C++, Objective-C, HTML, HTML/AJAX 조합들, XML, 또는 포함된 자바 애플릿을 갖는 HTML으로 작성된다. 일부 실시예들에서, API(305)는 컴퓨터 시스템 또는 서브시스템의 기능을 위해 최적화된 제한된 수의 바람직한 언어들을 지원할 수 있다. 다른 실시예들에서, API(305)는 공통 언어 계층을 포함하며, 상기 공통 언어 계층은 프로그래밍 언어를 중간 언어(intermediate language)로 변환하며, 상기 중간 언어는 상기 공통 언어 계층에 의해 지원되며, 컴퓨터 시스템(303)에 접속하거나 또는 네트워크(320)를 통해서 외부에 연결되는 API의 공통 언어 출력의 일부로서 포함된다. 이러한 방식으로, API(305)는 네트워크(320)를 통해 API 관리 시스템(310)과 같은 예시적 시스템(300)의 다른 구성요소들이 그들의 기능을 달성하도록 및 상이한 종류의 컴퓨터 시스템, 서브시스템, 및 실제 요구를 수용하도록 광범위하고 여러가지의 다양한 애플리케이션들을 효과적으로 제공할 수 있다.

API 관리 시스템(310)은 개시된 실시예들에 따른 동작들을 수행하기 위해 API 관리 시스템(310)의 하나 이상의 프로세서에 의해 사용되는 데이터 및/또는 소프트웨어 명령을 저장하도록 구성된 하나 이상의 저장 디바이스를 포함할 수 있거나 액세스할 수 있다. 예를 들어, API 관리 시스템(310)은 개시된 방법들에 특정한 동작들을 포함하는, 프로세서에 의해 실행될 때 몇몇 동작들을 수행하는 하나 이상의 소프트웨어 프로그램들을 저장하도록 구성된 메모리를 포함할 수 있다. 개시된 실시예들은 전용 태스크(dedicated task)를 수행하도록 구성된 개별 프로그램 또는 컴퓨터에 제한되지 않는다. 예를 들어, API 관리 시스템(310)은 단일 프로그램 또는 다수의 프로그램들을 저장하는 메모리를 포함할 수 있다. 또한, API 관리 시스템(310)은 API 관리 시스템(310)으로부터 원격으로 위치되는 하나 이상의 프로그램들을 실행할 수 있다. 예를 들어, API 관리 시스템(310)은, 실행될 때, 개시된 실시예들에 따른 동작들을 수행하는 (데이터베이스(330)와 같은) 원격 구성요소에 포함된 메모리 내에 저장된 하나 이상의 원격 프로그램들을 액세스할 수 있다.

데이터베이스(330)는 하나 이상의 컴퓨터 시스템 또는 구현된 컴퓨터 시스템일 수 있다. 데이터베이스(330)는 API의 정보와 연관된 동작을 생성, 관리, 및 제공하는 서버 소프트웨어를 포함할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 API 관리 시스템(310)에 의해 수행되는 동작에 대한 API의 정보와 연관된 서비스를 생성, 관리, 및 제공하는 데이터베이스(330)와 연관된 별도의 서버 또는 다른 컴퓨팅 디바이스와 접속할 수 있다.

데이터베이스(330)는 개시된 실시예들에 따른 API(305)의 정보를 저장하도록 구성될 수 있다. 데이터베이스(330)는 API가 등록되고 업데이트될 때 제공되는 API의 정보를 저장하도록 구성될 수 있으며, 정보는 인덱스 정보, 식별 정보, 액세스 정보, 소개 및 규칙, 개발, 및 디버깅 노트, 및 각 업데이트에 대한 정보 변경을 포함한다. 데이터베이스(330)는 API를 선택하거나 사용한 것에 대한 기록을 갖도록 데이터베이스(330) 내에 등록된 모든 API에 대한 엔트리(entry)를 각각 생성할 수 있다. API를 선택한 것에 대한 기록은 API의 각 부분의 각 API의 선택과 관한 것일 수 있다. API를 사용한 것에 대한 기록은 API의 각 부분의 각 API의 사용에 관한 것일 수 있다. 또한, 데이터베이스(330)는 네트워크(320)를 통해 API를 검색, 선택, 및 접속한 모든 사용자들에 대한 엔트리를 생성할 수 있다. 데이터베이스(330)는 네트워크(320)를 통한 또는 API 관리 시스템(310)과 연관된 각 사용자의 활동의 기록을 유지할 수 있다. 사용자의 활동은 API를 검색, 선택, 및 접속하는 것을 포함할 수 있고, 각각의 API에 대한 그들의 활동과 관련하여 기록될 수 있다.

데이터베이스(330)는 API 관리 시스템(310)과 연관될 수 있고 네트워크(320)에 액세스가능하게 될 수 있다. 일부 실시예들에서, 데이터베이스(330)는 API 관리 시스템(310)의 일부로서 제공될 수 있다. API 관리 시스템(310)은 실행될 때 개시된 실시예들에 따른 동작들을 수행하는 하나 이상의 프로그램들을 저장한 하나 이상의 스토리지 메모리를 가질 수 있다. API 관리 시스템(310)은 API의 정보와 연관된 동작을 생성, 관리, 및 제공하는 서버 소프트웨어를 포함하는 데이터베이스를 가질 수 있다. 또한, API 관리 시스템(310)은 데이터베이스(330)의 개시된 실시예들에 따른, API 사용 기록 및 모든 사용자들의 기록을 갖도록 그의 데이터베이스 부분 또는 하나 이상의 스토리지 메모리에 엔트리를 생성할 수 있다. 예를 들어, API 관리 시스템(310)이 API 검색을 위한 사용자로부터의 입력을 수신하는 경우, API 관리 시스템(310) 및/또는 데이터베이스(330)는 사용자 검색 API의 기록 내에 검색을 기록할 수 있다. 사용자가 사용하고자 하는 API의 일부를 사용자가 선택하는 경우, API 관리 시스템(310) 및/또는 데이터베이스(330)는 사용자 선택 API의 기록, API 선택의 기록, 및 API의 일부 선택의 기록 내에 선택을 기록할 수 있다. 그 다음, 사용자가 API의 일부와 접속할 때, API 관리 시스템(310) 및/또는 데이터베이스(330)는 사용자 사용 API의 기록, API 사용의 기록, 및 API의 부분의 사용 기록 내에 활동을 기록할 수 있다.

네트워크(320)는 도 3의 구성요소들 간에 통신을 제공하도록 구성될 수 있다. 예를 들어, 네트워크(320)는, API 관리 시스템(310)이 API 관리 시스템(310)의 구성요소들 간에 정보를 송수신할 수 있게 하는 인터넷, 근거리 네트워크(Local Area Network), 또는 다른 적절한 접속(들)과 같은, 통신을 제공하고, 정보를 교환하고, 및/또는 정보의 교환을 용이하게 하는 임의의 유형의 네트워크(기반구조를 포함함)일 수 있다. 일부 실시예들에서, 네트워크(320)는 도 1a의 하나 이상의 네트워크와는 별개의 네트워크일 수 있다. 다른 실시예들에서, 네트워크(320)는 도 1a의 하나 이상의 네트워크와 통합되거나 접속될 수 있다.

API 접속 시스템(318)은 사용자를 타겟 API에 접속하도록 구성될 수 있다. 일부 실시예들에서, API 접속 시스템(318)은 도 6의 단계 640(후술됨) 이후에 사용자를 타겟 API에 접속시키거나, API 관리 시스템(310)으로부터 요청을 수신한 후에 시작할 수 있다. API 접속 시스템(318)은 API 관리 시스템(310) 내에 등록된 모든 API를 저장하는 메모리를 가질 수 있어서, 사용자는 타겟 API 상에서 작업할 때, 타겟 API의 컴퓨터 시스템과 같은 다른 디바이스 또는 시스템과 통신하거나 접속하지 않으면서 API 접속 시스템 (318)의 서버 상에서 작업할 수 있다. API 접속 시스템(318)은 API를 저장하기 위한 메모리를 가질 수 있거나 또는 데이터베이스(330) 내에 원격으로 저장될 수 있다. 일부 실시예들에서, API 접속 시스템(318)은 API 관리 시스템(310)의 일부일 수 있다.

컴퓨터 시스템(303)은 하나 이상의 API(305)를 가질 수 있다. API 수단을 갖는 컴퓨터 시스템(303)은, 일부 실시예들에서, 컴퓨터 시스템(303)과 연관된 사용자 디바이스가 컴퓨터 시스템(303)으로부터 데이터를 요청하거나, 컴퓨터 시스템(303)의 데이터를 처리하거나, 또는 컴퓨터 시스템(303)에 데이터를 전송하는 애플리케이션을 동작시키는 것을 가능하게 하는 기능 및 코드를 저장한다는 것을 의미한다. 컴퓨터 시스템(303)은 API(305)의 소스 코드를 저장하는 메모리를 포함할 수 있다. 또한, API(305)의 소스 코드는 컴퓨터 시스템(303)으로부터 원격으로 저장될 수 있다. API 관리 시스템(310)은 도 4와 관련하여 후술되는 바와 같이, API 관리 시스템(310) 내에 컴퓨터 시스템(303)의 API를 등록하도록 구성될 수 있다.

도 3에 도시된 임의의 디바이스 및 시스템은 하나 이상의 프로세서, 하나 이상의 메모리, 및 하나 이상의 입력/출력(I/O) 디바이스를 포함할 수 있다. 이러한 구성요소들은 버스를 통해 또는 무선으로 서로 통신할 수 있다. 구성요소들은 단일 디바이스 또는 다수의 디바이스들 내에 상주할 수 있다. 일부 실시예들에서, 디바이스 및 시스템은 서버, 특별히-프로그램된 컴퓨터, 메인프레임 컴퓨터, 랩탑, 스마트폰, 모바일 디바이스, 또는 이러한 구성요소들의 임의의 조합의 형태를 취할 수 있다. 특정 실시예들에서, 디바이스 및 시스템은 개시된 실시예들에 따른 하나 이상의 동작을 수행하는 소프트웨어 명령의 저장, 실행, 및/또는 구현에 기초하여 특정 장치, 시스템 등으로서 구성될 수 있다. 상기 디바이스 및 시스템은 독립형일 수 있거나, 보다 큰 시스템의 일부일 수 있는 서브시스템의 일부일 수 있다.

프로세서는, 예를 들어 Intel™에 의해 제조된 Pentium^TM 또는 Xeon^TM 제품군, AMD™에 의해 제조된 Turion^TM 제품군, 또는 Sun Microsystems 또는 Apple Inc.에 의해 제조된 다양한 프로세서들 중 임의의 것으로부터의 마이크로프로세서와 같은, 하나 이상의 공지된 처리 디바이스를 포함하는, 중앙 처리 장치(CPU), 그래픽 처리 장치(GPU) 또는 유사한 마이크로프로세서를 포함할 수 있다. 프로세서는 단일 코어 또는 병렬 프로세스들을 동시에 실행하는 다중 코어 프로세서를 구성할 수 있다. 예를 들어, 프로세서는 가상 처리 기술로 구성된 단일 코어 프로세서일 수 있다. 특정 실시예들에서, 프로세서는 다수의 프로세스들을 동시에 실행하고 제어하기 위해 논리 프로세서를 사용할 수 있다. 프로세서는 다수의 소프트웨어 프로세스들, 애플리케이션들, 프로그램들 등을 실행, 제어, 가동, 조작, 저장 등을 할 수 있는 능력을 제공하도록 가상 머신 기술 또는 다른 공지된 기술을 구현할 수 있다. 또 다른 실시예에서, 프로세서는, 디바이스 및 시스템이 동시에 다수의 프로세스들을 실행하도록 병렬 처리 기능을 제공하도록 구성된 다중-코어 프로세서 장치(예를 들어, 듀얼(dual), 쿼드(quad) 코어 등)를 포함할 수 있다. 디바이스 및 시스템은 하나 이상의 프로세서들을 포함할 수 있고, 프로세서들에 대해 원격인 하나 이상의 다른 프로세서들과 함께 더 동작할 수 있다. 당업자는 본 명세서에 개시된 성능을 제공하는 다른 유형의 프로세서 장치들이 구현될 수 있다는 것을 이해할 것이다. 개시된 실시예들은 디바이스 및 시스템 내에 구성된 임의의 유형의 프로세서(들)로 제한되지 않는다.

메모리는 개시된 실시예들과 연관된 기능들을 수행하기 위해 프로세서에 의해 실행가능한 명령을 저장하도록 구성된 하나 이상의 스토리지 디바이스를 포함할 수 있다. 예를 들어, 메모리는 컴퓨터 하드 디스크, 랜덤 액세스 메모리(RAM), 착탈식 스토리지, 또는 원격 컴퓨터 스토리지를 포함할 수 있다. 예를 들어, 메모리는 프로세서에 의해 실행될 때 특정 기능을 수행하는 하나 이상의 소프트웨어 명령으로 구성될 수 있다. 개시된 실시예들은 전용 태스크를 수행하도록 구성된 별개의 프로그램 또는 컴퓨터로 제한되지 않는다. 또한, 프로세서는 디바이스 및 시스템으로부터 원격으로 위치되는 하나 이상의 프로그램들을 실행할 수 있다. 예를 들어, 컴퓨터 시스템(303), API(305), 또는 데이터베이스(330)는, 실행될 때, API 관리 시스템(310)(또는 그의 변형예)을 통해, 특정한 개시된 실시예들과 관련된 기능을 수행하는 하나 이상의 원격 프로그램에 액세스할 수 있다. 프로세서는 데이터베이스(330) 내에 위치된 하나 이상의 프로그램을 추가로 실행할 수 있다. 일부 실시예들에서, 명령은 API 관리 시스템(310) 외부에 위치된 클라우드 서버와 같은 외부 저장 디바이스에 저장될 수 있으며, 프로세서는 명령들을 원격으로 실행할 수 있다.

또한, 메모리는 예시된 시스템(300)이 개시된 실시예들에 따른 동작을 수행하기 위해 사용할 수 있는 임의의 형식의 임의의 유형의 정보를 반영하는 데이터를 저장할 수 있다. 메모리는 서버 애플리케이션과 같은 하나 이상의 애플리케이션, 네트워크 통신 프로세스, 및 프론트 엔드 시스템(103)의 상호작용 사용자 인터페이스와 같은, 임의의 다른 유형의 애플리케이션 또는 소프트웨어를 프로세서가 실행할 수 있게 하는 명령을 저장할 수 있다. 대안적으로, 명령, 애플리케이션 프로그램 등은 외부 스토리지에 저장될 수 있다. 예를 들어, API 관리 시스템(310)의 명령은 데이터베이스(330) 내에 저장될 수 있고, 네트워크(320) 또는 임의의 다른 적절한 네트워크를 통해 API 관리 시스템(310)과 통신한다. 메모리는 휘발성 또는 비휘발성, 자성, 반도체(예를 들어, EEPROM, 플래시 메모리 등), 테이프, 광학, 분리형, 비분리형, 또는 다른 유형의 스토리지 디바이스 또는 유형의(tangible)(즉, 비일시적) 컴퓨터 판독가능 매체일 수 있다.

I/O 디바이스는 디바이스의 사용자 또는 시스템의 디바이스로부터 디바이스 및 시스템으로 정보를 통신하기 위한 하드웨어 및/또는 하드웨어와 소프트웨어의 조합을 포함할 수 있다. 일부 실시예들에서, 사용자는 디바이스 또는 시스템의 디바이스의 직접적인 사용자일 수 있다. 일부 다른 실시예들에서, 사용자는 디바이스 및 시스템에 접속된 또 다른 사용자 디바이스 또는 시스템일 수 있다. 하드웨어 및 소프트웨어는, 예를 들어, 키보드, 마우스, 트랙볼, 오디오 입력 디바이스, 터치 스크린, 적외선 입력 인터페이스, 또는 유사한 디바이스일 수 있다.

도 4는 개시된 실시예들에 따른, 데이터베이스 내에 API를 등록하는 프로세스(400)를 도시한다.

단계 402에서, API 관리 시스템(310)은 시스템 내에 API를 등록하라는 요청을 수신한다. 일부 실시예들에서, 요청은 컴퓨터 시스템(303) 또는 컴퓨터 시스템(303)과 연관된 사용자 디바이스로부터의 요청일 수 있다. 일부 실시예들에서, 요청은 API(305) 또는 API(305)의 사용자로부터의 요청일 수 있다. 일부 다른 실시예들에서, 요청은 API 관리 시스템(310)의 인터페이스를 통해 요청을 직접 전송하는 사용자 디바이스의 사용자로부터의 요청일 수 있다. 요청은 요청을 전송할 때 인터페이스를 통해 사용자에 의해 주어진 API의 정보를 포함할 수 있다.

단계 404에서, API 관리 시스템(310)은 등록될 API의 정보를 수신한다. 정보는 인덱스 정보, 식별 정보, 액세스 정보, 허용 레벨에 관한 인증, 소개 및 규칙, 개발 및 디버깅 노트, 및 API의 이전 사용 기록을 포함할 수 있으며, 이들 모두는 집합적으로 API의 데이터로서 지칭될 수 있다. 액세스 정보는 API가 모든 사용자들, API들, 및 컴퓨터 시스템들에 대해 개방되어 있음을 나타낼 수 있다. 또한, 액세스 정보는, API가 항상 API를 사용하거나 접속하려고 하는 사용자, API 또는 컴퓨터 시스템으로부터의 요청을 요구함을 나타낼 수 있다. 또한, 액세스 정보는 API가 다음 중 적어도 하나일 수 있음을 나타낼 수 있다: (1) 일부 사용자들, API들, 또는 컴퓨터 시스템들에 대해 개방됨; (2) 일부 다른 사용자들, API들, 또는 컴퓨터 시스템들에 액세스불가능함; 또는 (3) 다른 일부 사용자들, API들, 또는 컴퓨터 시스템들이 API를 사용하거나 접속할 때 다른 일부 사용자들, API들, 또는 컴퓨터 시스템들로부터 요청을 요구함. 또한, 정보는 API의 문서를 포함할 수 있다. 일부 실시예들에서, 정보는 API를 등록하기 위한 요청 내에 포함될 수 있다. 일부 다른 실시예들에서, 정보는 API 관리 시스템(310)의 인터페이스와 사용자, API, 또는 컴퓨터 시스템 간의 상호작용 프로세스를 통해 수신된다.

단계 406에서, API 관리 시스템(310)은 예시적 시스템(300)의 API 데이터베이스 내에 API의 정보를 저장할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 그 자신의 API 데이터베이스를 가질 수 있고, 정보를 그 자신의 API 데이터베이스 내에 저장할 수 있다.

단계 408에서, API 관리 시스템(310)은 수신된 정보에 기초하여 API와 연관된 문서를 생성할 수 있다. 또한, API 관리 시스템(310)은 생성된 문서와 수신된 문서를 통합할 수 있다. 일부 실시예들에서, 문서를 생성하는 부분으로서, API 관리 시스템(310)은 API를 사용하기 위한 코드들을 생성하는 규칙들의 집합을 준비할 수 있다. 규칙들의 집합은 API 관리 시스템(310)이 API에 접속된 사용자에 대한 코드를 신속하고 자동으로 생성할 수 있게 함으로써, 사용자는 API의 모든 부분을 익히는 것을 건너뛸 수 있고 처음부터 프로그램을 개발할 필요가 없으며, 원하는 목적에 맞게 수신된 소스 코드를 적용할 수 있다.

단계 410에서, API 관리 시스템(310)은 예시적 시스템(300)의 API 데이터베이스 내에 API의 문서를 저장할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 그 자신의 API 데이터베이스를 가질 수 있고, 그 자신의 API 데이터베이스 내에 문서를 저장할 수 있다.

API 관리 시스템(310)은 도 5와 관련하여 후술되는 바와 같이, API의 정보를 업데이트하도록 구성될 수 있다.

도 5는 개시된 실시예들에 따른, 데이터베이스 내의 API 정보를 업데이트하기 위한 프로세스(500)를 도시한다.

단계 502에서, API 관리 시스템(310)은 시스템 내의 API의 정보를 업데이트하라는 요청을 수신한다. 일부 실시예들에서, 요청은 컴퓨터 시스템(303) 또는 컴퓨터 시스템(303)과 연관된 사용자 디바이스로부터의 요청일 수 있다. 일부 실시예들에서, 요청은 API(305) 또는 API(305)의 사용자로부터의 요청일 수 있다. 일부 다른 실시예들에서, 요청은 API 관리 시스템(310)의 인터페이스를 통해 요청을 직접 전송한 사용자 디바이스의 사용자로부터의 요청일 수 있다. 요청은 요청을 전송할 때 인터페이스를 통해 사용자에 의해 제공된 API의 정보를 포함할 수 있다.

단계 504에서, API 관리 시스템(310)은 업데이트할 API의 정보를 수신한다. 정보는 인덱스 정보, 식별 정보, 액세스 정보, 허용 레벨에 대한 인증, 소개 및 규칙, 개발 및 디버깅 노트, 및 API의 이전 사용 기록을 포함할 수 있으며, 이들 모두는 집합적으로 API의 데이터로 지칭된다. API 관리 시스템(310)은 새로운 정보를 이전 정보와 비교하고, API의 정보의 일부로서 저장된 엔트리로서의 정보 변경을 검출 및 기록할 수 있다. 요청이 API를 등록한 컴퓨터 시스템으로부터의 것이 아니면, API 관리 시스템(310)은 다음 단계로 진행하기 전에 컴퓨터 시스템에 업데이트 요청에 대해 통지하고 확인을 요구할 수 있다. 또한, 정보는 API의 문서를 포함할 수 있다. 일부 실시예들에서, 정보는 단계 502의 API의 정보를 업데이트하기 위한 요청에 포함될 수 있다. 일부 다른 실시예들에서, 정보는 API 관리 시스템(310)의 인터페이스와 사용자, API, 또는 컴퓨터 시스템 간의 상호작용 프로세스를 통해 수신된다.

단계 506에서, API 관리 시스템(310)은 예시적 시스템(300)의 API 데이터베이스 내의 API의 정보를 업데이트할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 그 자신의 API 데이터베이스를 가질 수 있고, 그 자신의 API 데이터베이스 내의 정보를 업데이트할 수 있다.

단계 508에서, API 관리 시스템(310)은 수신된 정보에 기초하여 API와 연관된 새로운 문서를 생성할 수 있다. 또한, API 관리 시스템(310)은 생성된 문서와 수신된 문서를 통합할 수 있다. 일부 실시예들에서, 문서를 생성하는 부분으로서, API 관리 시스템(310)은 API를 사용하기 위한 코드들을 생성하는 규칙들의 집합을 준비할 수 있다. 규칙들의 집합은 API 관리 시스템(310)이 API에 접속된 사용자 디바이스에 대한 소스 코드를 신속하고 자동으로 생성할 수 있게 함으로써, 사용자 디바이스의 사용자는 API의 모든 부분을 익히는 것을 건너뛸 수 있고 처음부터 프로그램을 개발할 필요가 없으며, 그 자신의 소스 코드 또는 기능을 생성된 소스 코드 상에 직접 추가할 수 있다.

단계 510에서, API 관리 시스템(310)은 예시적 시스템(300)의 API 데이터베이스 내에서 API의 문서를 업데이트할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 그 자신의 API 데이터베이스를 가질 수 있고, 그 자신의 API 데이터베이스 내에서 문서를 업데이트할 수 있다.

단계 512에서, API 관리 시스템(310)은 업데이트에 관하여 컴퓨터 시스템(303)에 통지를 전송할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 API에 액세스한 컴퓨터 시스템에만 통지를 전송할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 API를 사용했던 컴퓨터 시스템에만 통지를 전송할 수 있다. API 관리 시스템(310)은 이메일, 메시지, 또는 다른 특정 통신 툴을 통해 통지를 전송할 수 있다.

도 6은 개시된 실시예들에 따른, 문서를 사용자 디바이스에 제공하는 예시적인 프로세스를 도시한다. 단계 605에서, API 관리 시스템(310)은 사용자 디바이스로부터 입력을 수신할 수 있다. 일부 실시예들에서, 사용자 디바이스는 컴퓨터 시스템(303)과 연관될 수 있다. 일부 실시예들에서, 요청은 API(305) 또는 API(305)의 사용자로부터의 요청일 수 있다. 일부 다른 실시예들에서, 입력은 API 관리 시스템(310)의 인터페이스를 통해 요청을 직접 전송한 사용자로부터의 입력일 수 있다. 일부 실시예들에서, 입력은 원하는 API와 연관된 컴퓨터 시스템의 아이덴티티를 생략할 수 있다. 이는 사용자(예를 들어, 개발자)가 어떤 컴퓨터 시스템 또는 API를 사용할지를 미리 알 필요가 없다는 점에서 효율성을 제공한다.

일부 실시예들에서, 입력은 특정 기능의 아이덴티티를 생략할 수 있다. 예를 들어, API 관리 시스템(310)은 "약속된 배송 날짜(PDD) 데이터" 및 "배송 데이터"에 대한 요청을 포함하는 (예를 들어, FO 시스템(113)과 연관된 사용자 디바이스로부터의) 입력을 수신할 수 있다(예를 들어, 개발자는 PDD 데이터를 사용하는 FO 시스템(113)에 대한 애플리케이션을 개발중일 수 있다.). 사용자는 검색에 앞서 컴퓨터 시스템 또는 API를 선택할 필요가 없으며, 이는 API 문서 검토 및 검색을 위한 종래 시스템에 비해 장점을 제공한다.

일부 실시예들에서, 단계 605에서의 입력은 하나 이상의 조건을 포함할 수 있다. 조건은 데이터베이스(330)가 API들을 분류하는데 사용하는 조건일 수 있다. 예를 들어, 조건은: (1) 운송, 배송, 또는 프론트 엔드와 같은, API가 연관되는 시스템의 기능을 기술하는 키워드; (2) API가 시스템 또는 서브시스템과 관련되어 있는지 여부 및 API가 컴퓨터 시스템의 유일한 API인지 여부와 같은, API의 계층구조(hierarchy)를 기술하는 키워드 또는 카테고리적 용어(categorical term); (3) 버전을 나타내는 숫자, 날짜, 또는 날짜 범위; 또는 (4) 사용자가 또 다른 API로부터 찾고 있는 기능이나 데이터의 종류와 같은, 검색의 목적일 수 있다. 조건은, 사용자가 키워드를 규정하는 데 시간을 소비하기보다 정보를 선택할 수 있게 하는, API의 정보에 대응하는 API 관리 시스템(310)의 인터페이스에 의해 제공되는 카테고리적 용어일 수 있다. 일부 실시예들에서, 입력은 특정 조건을 만족시키는, 데이터베이스(330) 내에 저장된 API들의 리스트를 검색하라는 요청일 수 있다. 이러한 요청을 수신하면, API 관리 시스템(310)은 단계 610 또는 임의의 후속 단계로 진행하지 않고, 단지 API들의 리스트를 생성하여 생성된 리스트를 사용자에게 제공할 수 있다. 일부 다른 실시예들에서, 입력은 API 관리 시스템(310) 내에 저장되거나 데이터베이스(330) 내에 원격으로 저장된 명령을 실행함으로써 수행될 수 있는 임의의 요청일 수 있다.

단계 610에서, API 관리 시스템(310)은 타겟 API를 결정할 수 있다. 타겟 API는 입력을 만족시키는 API이며, 하나 이상의 추가 단계에 기초하여 결정될 수 있다. 단계 605에서 하나 이상의 조건들을 갖는 입력을 수신하는 경우, API 관리 시스템(310)은 조건들을 만족시키는 하나 이상의 API를 결정할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 사용자의 허가 레벨 및/또는 허가 레벨에 관한 API의 인증에 기초하여 사용자 디바이스의 사용자로 액세스할 수 없는 컴퓨터 시스템과 연관된 API를 우선 배제함으로써 타겟 API 결정을 시작할 수 있다. 예를 들어, 상급 개발자는 하급 개발자 또는 계약직 개발자보다 더 높은 허가 레벨을 가질 수 있으므로, 동일한 입력일 경우에, API 관리 시스템(310)은 하급 또는 계약직 개발자보다 상급 개발자에 대해서는 보다 큰 API 풀(pool)로부터 타겟 API를 결정할 수 있다. 이러한 프로세스는 타겟 API를 결정할 때 API 관리 시스템(310)의 효율 및 정확성을 향상시킬뿐만 아니라 API 정보의 불필요한 노출을 최소화한다(따라서 데이터 보안을 향상시킨다).

일부 실시예들에서, API 관리 시스템(310)은 API 사용 기록에 기초하여 조건을 만족시키는 하나 이상의 API로부터 타겟 API를 결정할 수 있다. 예를 들어, FO 시스템(113)과 연관된 사용자 디바이스의 사용자가 약속된 배송 날짜(PDD) 데이터를 사용하는 애플리케이션을 개발하고 있을 때, 사용자는 API 관리 시스템(310) 내에서 검색들 “배송” 및 “데이터”를 검색할 수 있고, 배송 및 주문 추적 시스템(111) 및 SAT 시스템(101)은 모두 조건을 만족시킬 수 있다. 그러나 FO 시스템(113)에 의한 SAT 시스템(101)의 API를 사용한 기록이 FO 시스템(113)에 의한 배송 및 주문 추적 시스템(111)의 API 사용 기록보다 많을 수 있으며, 따라서 API 관리 시스템(310)은 (FO 시스템(113)과 관련된 가장 연관된 기록을 갖는) SAT 시스템(101) 내의 API가 타겟 API이어야 한다고 결정할 수 있다. 타겟 API와 연관된 SAT 시스템(101) 내의 데이터는, 다른 API 또는 시스템과 연관된 데이터보다 FO 시스템(113) 내에서 사용자에 대해 보다 적합하고 잘조직화되어 있다. 드문 경우에, 사용자가 또 다른 시스템 내의 API에 접속하기를 원한다면, 사용자는 일부 다른 실시예들에 따라서, 리스트 중에서 API를 여전히 선택할 수 있다.

일부 실시예들에서, API 관리 시스템(310)은 사용자의 검색 이력, 선택 이력, 또는 사용 이력에 기초하여 조건을 만족시키는 하나 이상의 API로부터 타겟 API를 결정할 수 있다. 일부 다른 실시예들에서, API 관리 시스템(310)은 조건을 만족시키는 API를 사용자에게 제공할 수 있고, 사용자는 타겟 API를 선택할 수 있다. 일부 실시예들에서, 입력은 하나 이상의 조건을 포함하지 않지만, API의 선택을 목표로 하는 요청이고, API 관리 시스템(310) 내에 저장되거나 데이터베이스(330) 내에 원격으로 저장된 명령을 실행함으로써 수행될 수 있고, API 관리 시스템(310)은 저장된 명령에 기초하여 API의 선택을 특정하기 위해 인터페이스를 통해 사용자에게 추가 명령을 제공할 수 있다. 예를 들어, FO 시스템(113)과 연관된 사용자는 PDD와 관련된 데이터를 얻기를 원하지만 다른 시스템들에 대해서는 많이 알지 못할 수 있다. API 관리 시스템은 데이터베이스(330) 내에 저장된 API들의 데이터 중에서 자동으로 검색하고 PDD와 관련된 데이터를 갖는 API들의 리스트를 획득하기 위한 명령을 포함할 수 있다. API 관리 시스템은 검색 전에 이용가능한 API들의 지식을 요구하지 않으면서, 사용자가 타겟 API를 정확하고 효율적으로 선택할 수 있게 하는 PDD에 관련된 데이터의 설명부분 또는 데이터의 발췌부분을 갖는 API들의 리스트를 사용자에게 제공하기 위한 명령을 더 포함할 수 있다.

단계 615에서, API 관리 시스템(310)은 사용자가 타겟 API에 액세스할 수 있는지를 판단할 수 있다. 사용자가 API에 액세스할 수 있는지를 판단함에 있어서, API 관리 시스템(310)은 API와 연관된 API 데이터베이스 내에 저장된 데이터를 검색할 수 있다. 보다 구체적으로, API 관리 시스템(310)은 API와 관련된 액세스 정보를 고려할 수 있으며, 액세스 정보는 데이터의 일부일 수 있다. 액세스 정보는 API가: (A) 모든 사용자들, API들, 및 컴퓨터 시스템들에 대해 개방되어 있음; (B) API를 사용하거나 API에 접속하려는 사용자, API, 또는 컴퓨터 시스템으로부터의 요청을 항상 필요로 함; 또는 (C) 일부 사용자들, API들, 및 컴퓨터 시스템들에 개방되어 있으며, 일부 다른 사용자들, API들, 및 컴퓨터 시스템들이 API를 사용하거나 API에 접속하려 할 때 일부 다른 사용자들, API들, 및 컴퓨터 시스템들로부터의 요청을 요구함을 나타낼 수 있다. 또한, 액세스 정보는 API가 하나 이상의 사용자에게 액세스가능하지 않음을 나타낼 수 있다. 일부 다른 실시예들에서, 사용자가 타겟 API에 액세스할 수 있는지를 판단하는 것은 관련 사용자 허가를 결정하기 위해 타겟 API 또는 타겟 API의 컴퓨터 시스템과 통신하는 단계를 포함할 수 있다. 사용자 허가는 사용자가 타겟 API에 액세스하는 것이 허용되는지 여부에 대한 정보를 포함할 수 있다. 또한, 사용자 허가를 결정하기 위해 통신하는 단계는, 타겟 API에 액세스가 할당된 사용자들의 리스트를 요청하는 단계 및 사용자가 리스트 상에 있는지를 검사함으로써 사용자가 액세스할 수 있는지를 판단하는 단계를 포함할 수 있다.

일부 실시예들에서, 단계 615에서 액세스 정보가, API가 모든 사용자들, API들, 및 컴퓨터 시스템들에 대해 개방됨을 나타내면, API 관리 시스템(310)은 단계 635로 진행하여 사용자 디바이스에 타겟 API의 문서를 제공할 수 있다. 일부 실시예들에서, 단계 615에서 액세스 정보가, API가 API를 사용하거나 API에 접속하려고 하는 사용자 디바이스, API, 또는 컴퓨터 시스템으로부터의 요청을 항상 요구함을 나타내면, API 관리 시스템(310)은 단계 620으로 진행하여 사용자 디바이스의 사용자가 타겟 API로 요청을 전송할 것을 요구할 수 있다. 단계 615에서 액세스 정보가, 일부 사용자들, API들, 및 컴퓨터 시스템들에 대해 API가 개방되며 일부 다른 사용자들, API들, 및 컴퓨터 시스템들이 API를 사용하거나 API에 접속하려 할 때 일부 다른 사용자들, API들, 및 컴퓨터 시스템들로부터의 요청을 요구함을 나타내면, API 관리 시스템(310)은 본 명세서에 개시된 실시예들에 따라서, 적절하게 응답할 수 있다. 예를 들어, 사용자가 FO 시스템(113)과 연관된 사용자 디바이스로부터의 사용자이며 SAT 시스템(101)의 API와 접속하고자 하며, API와 연관된 액세스 정보가, API가 FO 시스템(113) 및 관리자인 임의의 사용자에게 공개됨을 나타내면, API 관리 시스템(310)은 사용자를 API에 접속시킬 수 있다. 그러나 사용자가 관리자가 아니며 노동 관리 시스템(125)의 사용자 디바이스를 사용하는 경우, API 관리 시스템(310)은 SAT 시스템(101)에 요청을 전송하도록 사용자 디바이스에 통지할 수 있다. 일부 다른 실시예들에서, 액세스 정보가, API가 하나 이상의 사용자에게 액세스가능하지 않음을 나타낼 수 있는 경우, API 관리 시스템(310)은 단계 645로 진행하여 그에 따라 사용자의 액세스를 거부할 수 있다. 일부 다른 실시예들에서, API 관리 시스템(310)은 인터페이스를 통해 사용자와 상호작용하여 API에 요청을 전송할 수 있다. API와 연관된 서류를 검색하는 대신 하나 이상의 조건을 만족시키는 API들의 리스트를 단순히 제공하는 것과 같이, 입력이 액세스 정보를 검사할 필요없이 실행되는 명령에 관련된 경우, API 관리 시스템(310)은 액세스 정보를 검사하지 않고 입력의 요청을 이행하도록 진행할 수 있다.

단계 620에서, API 관리 시스템(310)은 인터페이스 또는 이메일, 메시지, 또는 문서를 검색하기 전에 API가 사용자에게 요청을 API에 전송할 것을 요구하는 다른 특정한 통신 툴들 통해 사용자에 통신할 수 있다.

단계 625에서, 사용자가 타겟 API에 요청을 전송하면, API 관리 시스템(310)은 타겟 API 또는 타겟 API가 연관된 컴퓨터 시스템에 의해 네트워크(320)를 통해 통지를 수신할 수 있다. API 관리 시스템(310)은 단계 630으로 진행할 수 있다. API 관리 시스템(310)이, 특정 기간 후에, 사용자가 타겟 API로 요청을 전송하지 않았다는 것을 결정하면, API 관리 시스템(310)은 단계 645로 진행하여 액세스를 거부할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 타겟 API와 연관된 데이터베이스(330) 내에 저장된 규칙들의 집합을 참조하여 기간의 길이를 결정할 수 있다. 일부 다른 실시예들에서, API 관리 시스템(310)은 기간의 길이를 특정하는, 메모리 내에 저장되거나 데이터베이스(330) 내에 원격으로 저장된 명령을 가질 수 있다.

단계 630에서, API 관리 시스템(310)은 타겟 API 또는 상기 타겟 API와 연관된 컴퓨터 시스템으로부터, 상기 타겟 API 또는 컴퓨터 시스템이 사용자로의 액세스를 승인했다는 승인사항을 수신할 수 있다. 이러한 승인을 수신하면, API 관리 시스템(310)은 단계 635로 진행할 수 있다. API 관리 시스템(310)이 특정 기간 후에 승인을 받지 못했거나 거부를 수신한 경우, API 관리 시스템(310)은 단계 645에서 액세스를 거부하도록 진행할 수 있다.

단계 635에서, API 관리 시스템(310)은 타겟 API의 문서를 사용자 디바이스에 제공할 수 있다. 문서는 어느 부분이 유용할 수 있는지를 찾기 위해 사용자의 많은 시간과 노력을 요구하는 엄청난 양일 수 있다. API 관리 시스템(310)은 타겟 API의 일부분과 연관된 문서를 사용자 디바이스에 제공하기 위한 명령을 자동으로 실행함으로써 이러한 프로세스의 효율을 향상시킬 수 있으며, 이는 타겟 API 또는 문서의 어느 부분이 필요한지 찾는 데 있어 사용자가 많은 시간와 노력을 절약할 수 있게 한다. 따라서, 일부 실시예들에서, API 관리 시스템(310)은 사용자 디바이스에 타겟 API의 부분의 문서를 제공할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 사용자가 선택하도록 하기 위한 타겟 API의 하나 이상의 부분들을 사용자 디바이스에 제공할 수 있다. API 관리 시스템(310)은 API의 부분들과 연관된 정보를 메모리 내에 저장하거나 데이터베이스(330) 내에 원격으로 저장하여 사용자가 어느 부분들이 필요한지 선택하는 것을 도울 수 있다.

일부 실시예들에서, 타겟 API의 일부를 결정하는 프로세스에서 자동화의 정도를 더 향상시키기 위해, API 관리 시스템(310)은 타겟 API의 부분들의 선택을 자동으로 좁힐 수 있다. API 관리 시스템(310)은 타겟 API 사용 기록을 참조하여, 이러한 기록사항을 타겟 API의 부분들을 결정하기 위해 입력과 함께 고려할 수 있다. 또한, API 관리 시스템(310)은 타겟 API 사용 기록을 볼 수 있고, 타겟 API의 부분들을 결정하기 위해 입력과 함께 고려할 수 있다. API 관리 시스템(310)은 결정을 돕기 위해 API와 연관된 정보를 볼 수도 있다. 일부 다른 실시예들에서, API 관리 시스템(310)은 본 명세서에 개시된 실시예들의 조합을 사용할 수 있고, 타겟 API의 부분들을 결정할 때 상이한 실시예들에 대한 가중 계수(weight coefficient)를 할당할 수 있다. API 관리 시스템(310)은 타겟 API 사용 기록, 타겟 API 또는 입력 사용 기록을 사용하여 타겟 API의 부분들의 선택을 좁힐 수 있고, 사용자 디바이스에 대해 선택을 좁힌 후 부분들의 선택을 제공할 수 있다. 예를 들어, API 관리 시스템(310)은 단계 605에서 사용자 디바이스로부터 입력을 수신하여, 특정 기능을 수행하고, 사용자 디바이스의 사용자에 대한 타겟 API를 결정하고, 사용자가 타겟 API에 액세스를 하는, API를 검색할 수 있다. 그러나 타겟 API는 20개의 부분들을 가지며, 각각은 많은 문서를 가지며, 20개의 부분들 중 단지 하나 또는 소수만이 기능과 관련된다. 기능을 수행하는 API 부분을 사용자가 수동으로 찾도록 하는 대신에 API 관리 시스템(310)은 먼저 선택을 좁힐 수 있다. 단계 635에서, API 관리 시스템(310)은 타겟 API 사용 기록을 참조하고, 더 높은 가중 계수를 사용 기록에 할당하여, 타겟 API의 모든 부분에 대한 인기도의 평가를 얻을 수 있다. 그 다음, API 관리 시스템(310)은 입력의 조건을 만족하지 않거나 높은 인기도를 가지지 않는 부분들을 배제한다. API 관리 시스템(310)은 선택을 위해 사용자 디바이스에 좌측 부분을 좁혀진 리스트로서 제공한다. 또한, API 관리 시스템(310)은 사용자의 선택을 돕기 위해, 설명, 규칙들의 집합, 및 JSON 코드들의 발췌와 같은 타겟 API의 좁혀진 부분과 연관된 정보를 검색한다.

단계 635에서, 타겟 API의 부분이 결정된 후에, API 관리 시스템(310)은 타겟 API의 부분과 연관된 문서를 사용자 디바이스에 제공할 수 있다. 전체 타겟 API의 문서가 필요하다고 결정되면, API 관리 시스템(310)은 전체 문서를 제공할 수 있다.

단계 635의 일부 실시예들에서, API 관리 시스템(310)은 사용자 디바이스에 사용자에 대한 타겟 API 또는 타겟 API의 부분과 연관된 소스 코드를 제공할 수 있다. 소스 코드는 .Net Framework, .NET Compact Framework(및 Visual Basic, C 등과 같은 관련 언어들), Java, C++, Objective-C, HTML, HTML/AJAX 조합들, XML, 또는 포함된 자바 애플릿을 갖는 HTML과 같은 API들 내에서 일반적으로 사용되는 언어로 되어 있을 수 있다. 또한, 소스 코드는 API 문서 및 문서 인터페이스에 보다 특정한 JSON 또는 YAML과 같은 프로그래밍 언어로 되어 있을 수 있다. 소스 코드는 타겟 API에 직접 적용가능할 수 있다. 예를 들어, 사용자가 C++ 언어를 사용하는 API를 사용하고 타겟 API가 JAVA를 사용하는 경우, API 관리 시스템(310)은, 사용자가 타겟 API와 접속하고 사용자가 의도하는 기능 또는 부분과 함께 작업하도록 직접 적용될 수 있는 JAVA 내 소스 코드를 사용자에게 자동 생성하여 제공할 수 있다. 이러한 자동화는 상이한 API들 및 컴퓨터 시스템들에 걸쳐 사용자가 애플리케이션을 프로그래밍 및 사용하는 효율을 상당히 향상시킬 수 있다. 또한, 사용자가 타겟 API상에서 작업할 때, 사용자는 때때로 다른 API에도 액세스할 필요가 있다. 예를 들어, 내부 프론트 엔드 시스템(105)의 API의 사용자가 운송 시스템(107)에 접속하는 애플리케이션 상에서 작업하는 경우, 사용자는 또한 모바일 디바이스들(107A 내지 107C)의 API들에 개별적으로 액세스하여 디바이스들의 각 유형에 대해 최적화된 별도의 애플리케이션 기능을 생성할 필요가 있을 수 있다. 사용자가 이러한 상황에서 효율적으로 작업할 수 있게 하기 위해, 단계 635에서, 타겟 API 인 운송 시스템(107) API의 부분과 연관된 문서 및 소스 코드를 생성하는 것 이외에, API 관리 시스템(310)은 또한 모바일 디바이스들(107A 내지 107C)의 대응하는 API들의 문서 및 보충 소스 코드를 생성할 수 있다.

API 관리 시스템(310)은 선택되는 타겟 API의 부분과 연관된 API의 부분을 결정함으로써 보충 소스 코드를 생성할 수 있다. 상기 결정은 다음 중 하나 이상을 포함할 수 있다: (A) 사용자가 API 관리 시스템(310)에 의해 제공된 리스트 내의 API의 부분을 선택하는 것을 결정함; (B) API 관리 시스템(310)이 타겟 API의 부분 사용 기록을 참조하고, 어떤 API 및 어떤 부분이 사용시 타겟 API의 선택된 부분과 연관되는지를 찾음; (C) API 관리 시스템(310)이 타겟 API에 적용가능한 소스 코드를 생성하기 위한 명령에 대해 타겟 API의 부분의 정보를 봄; (D) API 관리 시스템(310)이 타겟 API의 부분과 함께 사용될 수도 있고 사용되지 않을 수도 있는 API의 가장 많이 사용되는 부분을 결정하기 위해 관련 기록을 봄; (E) API 관리 시스템(310)이 타겟 API와 연관된 API를 결정하기 위해 다른 기록을 참조하고, 보충 소스 코드를 생성하기 위해 API와 연관된 정보를 참조함; (F) 사용자가 선택하도록 좁혀진 리스트를 제공하기 위해 (A) 및 다른 자동 방법들을 제외하고 본 명세서에 개시된 방법들의 조합을 사용함; 또는 (G) 보충 소스 코드를 생성하기 위해 본 명세서에 개시된 방법들 및 다른 자동 방법들의 조합을 사용함. 따라서 API 관리 시스템(310)은 사용자를 돕는 데 있어 고도의 자동화를 달성할 수 있다. 일부 실시예들에서, API 관리 시스템(310)은 전체적으로 단계 635의 프로세스를 최적화하는 메모리 내에 저장되거나 데이터베이스(330) 내에 원격으로 저장된 명령을 가질 수 있다. 다양한 인자들에 따라, API 관리 시스템(310)은 단계 635의 일부로서 본 명세서에 개시된 실시예들 중 일부를 선택할 수 있다. 예를 들어, 내부 프론트 엔드 시스템(105)의 사용자가 운송 시스템(107)의 API 상에서 작업하고 디바이스들(107A 내지 107C)로부터 전송된 데이터를 사용하는 애플리케이션을 개발 또는 테스트하기를 원할 때, 사용자는 모바일 디바이스들(107A 내지 107C)의 각 유형에 대한 개별 프로그램을 생성하여 프로그램이 디바이스로부터의 상이한 유형의 데이터와 보다 잘 작동할 수 있기를 원할 수 있다. 또한, 사용자는 애플리케이션을 개선하기 위해 SAT 시스템(101)과 관련된 특정 기능을 통합하고자 할 수 있다. 이러한 상황에서, API 관리 시스템(310)은: (A) 운송 시스템의 타겟 API와 연관된 정보 및 타겟 API를 사용한 기록으로부터, 모바일 디바이스들(107A 내지 107C) 및 SAT 시스템(101)의 API의 어느 부분에 사용자가 액세스할 필요가 있는지를 결정할 수 있고; (B) 타겟 API 및 연관 API의 액세스 정보로부터, 사용자가 액세스함을 결정하며; (C) 생성된 문서, 소스 코드, 및 보충 소스 코드가 사용자에게 지나치게 많을 정도로 소정 임계치를 초과하지 않는 것과 API 기록 사항에 기초하여 이것들이 인기있는 것을, 메모리 내에 저장된 명령에 기초하여 결정하였다. 그런 다음, API 관리 시스템(310)은, 사용자에게 더 검색하거나 선택하도록 요구하지 않으면서, 시스템(107)의 타겟 API 및 디바이스들(107A 내지 107C) 및 SAT 시스템(101)의 API와 연관된 문서, 소스 코드, 및 보충 소스 코드를 사용자에게 제공하도록 진행할 수 있다.

본 개시가 제시되고 그것의 특정 실시예를 참조하여 설명되었지만, 본 개시는 다른 환경에서 변형없이 실시될 수 있음을 이해할 것이다. 전술한 설명은 설명을 목적으로 제공되었다. 이는 포괄적인 것이 아니며 개시된 정확한 형태 또는 실시예로 한정되지 않는다. 변형예 및 적응예는 개시된 실시예들의 상세 설명 및 실시의 고려로부터 통상의 기술자에게 명백할 것이다. 추가적으로, 개시된 실시예들의 양상들이 메모리에 저장되는 것으로 설명되었지만, 통상의 기술자는 이러한 양상들이 또한 2차적 저장 디바이스(예를 들어, 하드 디스크 또는 CD ROM, 다른 형태의 RAM 또는 ROM, USB 매체, DVD, Blu-ray 또는 기타 광 드라이브 매체)와 같은 다른 유형의 컴퓨터 저장 매체에 저장될 수 있는 것이 명백할 것이다.

기재된 설명 및 개시된 방법들에 기초하는 컴퓨터 프로그램은 숙련된 개발자의 기술 내에 있다. 다양한 프로그램 또는 프로그램 모듈이 당업계에서 알려진 임의의 기술을 사용하여 만들어질 수 있으며, 기존 소프트웨어와 관련되어 설계될 수 있다. 예를 들어, 프로그렘 섹션 또는 프로그램 모듈은 .Net Framework, .Net Compact Framework(및 Visual Basic, C 등과 같은 관련 언어), Java, C ++, Objective-C, HTML, HTML / AJAX 조합, XML 또는 Java 애플릿이 포함된 HTML으로 또는 이것들에 의하여 설계될 수 있다.

이에 더하여, 예시적 실시들이 본 명세서에 설명되었지만, 등가 요소들, 변형물, 생략물, (예를 들어, 다양한 실시예들에 걸친 양상들의) 조합물, 적응물 및/또는 대체물을 갖는 임의 및 모든 실시예의 범위가 본 개시에 기초하여 통상의 기술자에게 이해될 것이다. 청구 범위에서의 제한은 청구 범위에서 사용된 언어에 기초하여 광범위하게 해석되어야 하며, 본 명세서 또는 본 출원의 기소 중에 설명된 예시들로 제한되지 않는다. 예시들은 비배타적으로 해석되어야 한다. 이에 더하여, 개시된 방법들의 단계들은 단계들의 재정렬 및/또는 단계를 삽입 또는 삭제하는 것을 포함하는 임의의 방식으로 변형될 수 있다. 따라서, 상세한 설명과 예시들은 시례로서만 고려되어야 하고, 이하의 청구 범위 및 등가물의 전체 범위에 의해 나타내지는 진정한 범위와 정신을 갖는 것으로 의도된다.

Claims

애플리케이션 프로그래밍 인터페이스(API) 정보를 관리하기 위한 컴퓨터 구현 시스템으로서,
적어도 하나의 프로세서;
API들과 연관된 데이터를 저장하는 API 데이터베이스―각 API는 적어도 하나의 컴퓨터 시스템과 연관됨―; 및
상기 적어도 하나의 프로세서에 의해 실행될 때, 상기 프로세서가 동작들을 수행하게 하는 명령들을 저장하는 적어도 하나의 메모리를 포함하며,
상기 동작들은:
API 등록 요청 및 API와 연관된 API 데이터를 수신하는 동작―상기 API 데이터는 액세스 정보를 포함하며, 상기 액세스 정보는 상기 API에 액세스하는 것이 허가된 엔티티 그룹을 식별하는 것임―
상기 API 등록 요청에 기초하여 상기 API와 연관된 문서를 생성하는 동작;
상기 API 등록 요청에 기초하여 상기 API를 사용하기 위한 코드를 생성하기 위한 규칙 집합을 생성하는 동작―상기 규칙 집합은 상기 엔티티 그룹에 속하는 사용자가 상기 API에 접속되었을 때 상기 시스템이 상기 API와 연관된 코드를 생성하는데 사용하기 위해 구성된 것임―; 및
상기 생성된 문서와 상기 API 데이터를 상기 API 데이터베이스에 저장하는 동작―상기 시스템은 요청에 응답하여 사용자 디바이스를 상기 API 데이터에 접속시키도록 구성됨―을 포함하는
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 API 등록 요청 및 API 데이터는 상기 API를 사용하도록 구성된 사용자 디바이스로부터 수신되는 것인
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 API 등록 요청 및 API 데이터는 제품에 대해 약속된 배달 날짜를 계산하도록 구성된, 풀필먼트 최적화 시스템 내 사용자 디바이스로부터 수신되는 것인
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 API 데이터는 인덱스 정보, 식별 정보, 허가 레벨 인증 정보, 소개 노트(introduction note), 규칙, 개발 및 디버깅 노트, 또는 상기 API의 이전 사용에 대한 기록 중 적어도 하나를 포함하는 것인
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 액세스 정보로 식별되는 상기 엔티티 그룹은 임의의 사용자, 임의의 API, 또는 임의의 컴퓨터 시스템 중 적어도 하나를 포함하는 것인
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 액세스 정보로 식별되는 상기 엔티티 그룹은 액세스할 수 있는 특정 그룹의 사용자, API들, 또는 컴퓨터 시스템; 액세스할 수 없는 특정 그룹의 사용자, API들, 또는 컴퓨터 시스템; 또는 상기 API에 접속하는 요청을 수신하는 것에 대한 액세스 조건 중 적어도 하나를 포함하는 것인
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 문서는 상기 API 데이터에 기초하여 생성되는 것인
컴퓨터 구현 시스템.
청구항 7에 있어서,
상기 동작들은
사용자 디바이스로부터 입력을 수신하는 동작;
상기 API를 상기 입력의 타겟 API로 식별하는 동작;
상기 입력에 응답하여, 상기 문서를 검색하는 것 또는 상기 타겟 API와 연관된 소스 코드를 생성하는 것 중 적어도 하나를 수행하는 동작; 및
상기 사용자 디바이스에 상기 문서 또는 상기 생성된 소스 코드 중 적어도 하나를 제공하는 동작을 더 포함하는
컴퓨터 구현 시스템.
청구항 8에 있어서,
상기 동작들은
상기 타겟 API와 다른 적어도 하나의 API와 연관된 보충 소스 코드가 상기 입력에 대한 응답이라고 결정하는 동작;
상기 타겟 API와 다른 적어도 하나의 API와 연관된 상기 보충 소스 코드를 생성하는 동작―상기 보충 소스 코드는 상기 생성된 소스 코드에 추가됨―을 더 포함하는
컴퓨터 구현 시스템.
청구항 8에 있어서,
상기 입력은 적어도 하나의 키워드를 포함하고; 그리고
상기 API는 상기 적어도 하나의 키워드에 기초하여 상기 타겟 API로 식별된 것인
컴퓨터 구현 시스템.
청구항 8에 있어서,
상기 API는 상기 API의 사용에 대한 기록에 기초하여 상기 타겟 API로 식별된 것인
컴퓨터 구현 시스템
청구항 8에 있어서,
상기 API는 상기 사용자 디바이스와 연관된 탐색 이력, 상기 사용자 디바이스와 연관된 선택 이력, 또는 상기 사용자 디바이스와 연관된 사용 이력 중 적어도 하나에 기초하여, 상기 타겟 API로 식별된 것인
컴퓨터 구현 시스템.
청구항 8에 있어서,
상기 동작들은
API 리스트를 상기 사용자 디바이스에 제공하는 동작―상기 리스트는 상기 입력에 기초하는 것이고 상기 API를 포함함―;
상기 사용자 디바이스로부터 상기 API의 선택을 수신하는 동작―상기 API는 상기 수신된 선택에 기초하여 상기 타겟 API로 식별됨―을 더 포함하는
컴퓨터 구현 시스템.
청구항 13에 있어서,
상기 API 리스트는 추가로 상기 API들과 연관된 인기도에 기초하는
컴퓨터 구현 시스템.
청구항 1에 있어서,
상기 동작들은
API 업데이트 요청과 추가 API 데이터를 수신하는 동작을 더 포함하는
컴퓨터 구현 시스템.
청구항 15에 있어서,
상기 동작들은
적어도 상기 규칙 집합 또는 상기 문서를 업데이트하는 동작을 더 포함하는
컴퓨터 구현 시스템.
청구항 16에 있어서,
상기 동작들은
통지를 적어도 하나의 컴퓨터 시스템에 전송하는 동작을 더 포함하는
컴퓨터 구현 시스템.
청구항 17에 있어서,
상기 적어도 하나의 컴퓨터 시스템은 상기 API에 액세스하는 것이 허가된 엔티티 그룹의 일부로서 식별된 것인
컴퓨터 구현 시스템.
애플리케이션 프로그래밍 인터페이스(API) 정보를 관리하기 위한 방법으로서,
API 등록 요청 및 API와 연관된 API 데이터를 수신하는 단계―상기 API 데이터는 액세스 정보를 포함하며, 상기 액세스 정보는 상기 API에 액세스하는 것이 허가된 엔티티 그룹을 식별하는 것임;
상기 API 등록 요청에 기초하여 상기 API와 연관된 문서를 생성하는 단계;
상기 API 등록 요청에 기초하여 상기 API를 사용하기 위한 코드를 생성하기 위한 규칙 집합을 생성하는 단계―상기 규칙 집합은 상기 엔티티 그룹에 속하는 사용자가 상기 API에 접속되었을 때 상기 시스템이 상기 API와 연관된 코드를 생성하는데 사용하기 위해 구성된 것임―; 및
상기 생성된 문서와 상기 API 데이터를 상기 API 데이터베이스에 저장하는 단계―상기 시스템은 요청에 응답하여 사용자 디바이스를 상기 API 데이터에 접속시키도록 구성됨―를 포함하는
애플리케이션 프로그래밍 인터페이스 정보를 관리하기 위한 방법.
애플리케이션 프로그래밍 인터페이스(API) 정보를 관리하기 위한 컴퓨터 구현 시스템으로서,
적어도 하나의 프로세서;
API들과 연관된 데이터를 저장하는 API 데이터베이스―각 API는 적어도 하나의 컴퓨터 시스템과 연관됨―; 및
상기 적어도 하나의 프로세서에 의해 실행될 때, 상기 프로세서가 동작들을 수행하게 하는 명령들을 저장하는 적어도 하나의 메모리를 포함하며,
상기 동작들은:
API 등록 요청 및 API와 연관된 API 데이터를 수신하는 동작―상기 API 데이터는 액세스 정보를 포함하며, 상기 액세스 정보는 상기 API에 액세스하는 것이 허가된 엔티티 그룹을 식별하는 것임―;
상기 API 등록 요청에 기초하여 상기 API와 연관된 문서를 생성하는 동작;
상기 API 등록 요청에 기초하여 상기 API를 사용하기 위한 코드를 생성하기 위한 규칙 집합을 생성하는 동작―상기 규칙 집합은 상기 엔티티 그룹에 속하는 사용자가 상기 API에 접속되었을 때 상기 시스템이 상기 API와 연관된 코드를 생성하는데 사용하기 위해 구성된 것임―;
상기 생성된 문서와 상기 API 데이터를 상기 API 데이터베이스에 저장하는 동작―상기 시스템은 요청에 응답하여 사용자 디바이스를 상기 API 데이터에 접속시키도록 구성됨―;
사용자 디바이스로부터 입력을 수신하는 동작;
상기 사용자 디바이스가 상기 API에 액세스하는 것이 인증되었다고 결정하는 동작;
상기 사용자 디바이스가 상기 API에 액세스하는 것이 인증되었다는 결정에 기초하여, 상기 API를 상기 입력의 타겟 API로 식별하는 동작;
상기 입력에 응답하여, 상기 문서를 검색하는 것 또는 상기 타겟 API와 연관된 소스 코드를 생성하는 것 중 적어도 하나를 수행하는 동작; 및
상기 사용자 디바이스에 상기 문서 또는 상기 생성된 소스 코드 중 적어도 하나를 제공하는 동작을 포함하는
컴퓨터 구현 시스템.