KR102523033B1 - 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 - Google Patents
프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 Download PDFInfo
- Publication number
- KR102523033B1 KR102523033B1 KR1020210148297A KR20210148297A KR102523033B1 KR 102523033 B1 KR102523033 B1 KR 102523033B1 KR 1020210148297 A KR1020210148297 A KR 1020210148297A KR 20210148297 A KR20210148297 A KR 20210148297A KR 102523033 B1 KR102523033 B1 KR 102523033B1
- Authority
- KR
- South Korea
- Prior art keywords
- return
- item
- api call
- refund
- subset
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims description 168
- 230000008569 process Effects 0.000 title claims description 129
- 238000012545 processing Methods 0.000 claims abstract description 40
- 230000002950 deficient Effects 0.000 claims abstract description 5
- 230000009471 action Effects 0.000 claims description 10
- 238000004891 communication Methods 0.000 description 52
- 238000012384 transportation and delivery Methods 0.000 description 41
- 238000007726 management method Methods 0.000 description 38
- 230000008901 benefit Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 16
- 230000004044 response Effects 0.000 description 13
- 230000006870 function Effects 0.000 description 11
- 239000003999 initiator Substances 0.000 description 11
- 238000013068 supply chain management Methods 0.000 description 6
- 238000012795 verification Methods 0.000 description 6
- 238000001514 detection method Methods 0.000 description 5
- 230000008570 general process Effects 0.000 description 5
- 230000002452 interceptive effect Effects 0.000 description 5
- 238000012856 packing Methods 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000000977 initiatory effect Effects 0.000 description 4
- 229920001690 polydopamine Polymers 0.000 description 4
- 238000012552 review Methods 0.000 description 4
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 238000010801 machine learning Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000005192 partition Methods 0.000 description 3
- 238000012546 transfer Methods 0.000 description 3
- 230000002776 aggregation Effects 0.000 description 2
- 238000004220 aggregation Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000007670 refining Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 102100028626 4-hydroxyphenylpyruvate dioxygenase Human genes 0.000 description 1
- 238000007792 addition Methods 0.000 description 1
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000033228 biological regulation Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 230000001276 controlling effect Effects 0.000 description 1
- 238000013506 data mapping Methods 0.000 description 1
- 238000013501 data transformation Methods 0.000 description 1
- 238000002716 delivery method Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 230000003203 everyday effect Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 230000008014 freezing Effects 0.000 description 1
- 238000007710 freezing Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 229920002469 poly(p-dioxane) polymer Polymers 0.000 description 1
- 230000001012 protector Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000001105 regulatory effect Effects 0.000 description 1
- 238000010079 rubber tapping Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/083—Shipping
- G06Q10/0837—Return transactions
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
- G06Q20/407—Cancellation of a transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
-
- 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/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0633—Workflow analysis
-
- 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
-
- 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
- G06Q10/0833—Tracking
-
- 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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/085—Payment architectures involving remote charge determination or related payment systems
-
- 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/01—Customer relationship 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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Economics (AREA)
- Finance (AREA)
- Human Resources & Organizations (AREA)
- Marketing (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Tourism & Hospitality (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Data Mining & Analysis (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Educational Administration (AREA)
- Game Theory and Decision Science (AREA)
- Telephonic Communication Services (AREA)
- Monitoring And Testing Of Exchanges (AREA)
Abstract
네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 반품을 처리하기 위한 컴퓨터 구현 시스템이 개시된다. 이 시스템은 반품 아이템의 반품을 요청하는 사용자 디바이스로부터 반품 API 호출을 수신하고; 네트워크 데이터베이스의 데이터 레코드에 대해 반품 API 호출을 검증하고; 반품 아이템이 복수의 개별 아이템을 포함한다고 결정하고; 개별 아이템의 서브세트가 결함이 있는지 여부를 결정하기 위해 반품 API 호출의 반품 코드를 분석하고; 개별 아이템의 서브세트에 상응하는 반품 아이템의 가격분을 결정하고; 반품 아이템의 가격분을 환불로서 발행하기 위한 환불 API 호출을 생성하고; 환불을 기록하기 위해 네크워크 데이터베이스의 데이터 레코드를 업데이트하고; 그리고 반품 API 호출의 승인에 대한 알림을 사용자 디바이스에 전송하도록 구성될 수 있다.
Description
본 개시는 일반적으로 확장성을 향상시키기 위해 선택 프로세스를 능률화하기 위한 컴퓨터화된 시스템 및 방법에 관한 것이다. 특히, 본 개시의 실시예는 보다 능률화된 프로세스로부터 이익을 얻을 수 있는 전자 요청의 서브세트를 식별하여 네트워크 부하를 감소시키고 확장성을 향상시키는 독창적이고 비전통적인 시스템에 관한 것이다.
컴퓨터 네트워킹의 발전은 많은 다양한 프로세스를 온라인으로 이동시켜 빨라지고, 원격 처리 및 자동화가 가능해졌다. 특히, 사람의 개입이 필요했던 비즈니스 프로세스의 많은 수가 이제는 온라인으로 수행되어 수십만 또는 수백만의 트랜직션이 매일 기업 네트워크 내에서 이루어질 정도가 됐다.
이러한 트랜잭션은 일반적으로 상이한 시스템, 서브시스템 및 모듈 간의 통신을 가능하게 하는 API(Application Programming Interface)를 사용하여 구현된다. 트랜잭션을 처리하기 위해 API를 사용하는 통신(API 호출로도 알려짐)은 보통 크기가 작아(예를 들어, 수백 바이트 미만) 네트워크에 큰 부하를 주지 않는다. 더 빠른 데이터 전송을 가능하게 하는 네트워크 통신의 발전은 또한 네트워크가 큰 부하를 지원할 수 있는 것을 보장한다.
그러나, 더 많은 시스템, 서브시스템 또는 모듈이 소정 작업을 전문적으로 처리하기 위해 네트워크에 추가되고, 트랜잭션을 완료하기 위해 관여되는 시스템, 서브시스템 또는 모듈의 수가 증가함에 따라, 문제가 발생한다. 예를 들어, 온라인 쇼핑몰에 아이템을 반품하기 위한 간단한 요청은, 반품 요청을 수신한 시스템; 초기 주문을 관리한 시스템; 주문에 대한 결제를 처리한 시스템; 반품 배송을 관리하는 시스템; 반품 아이템을 수령하고 재입고하는 시스템, 또한 상기 시스템들과 함께 기능하는 서브-시스템 및 모듈, 간의 API 호출을 포함할 수 있다. 이 문제는 네트워크가 하루에 수백만 명의 사용자 또는 트랜잭션을 지원해야 할 때 악화된다. 100바이트 정도의 작은 API 호출도 빠르게 확대되어 네트워크에 많은 부하가 걸릴 수 있다.
각 새로운 트랜잭션(예를 들어, 주문 처리)에 대해 동일한 수의 시스템 및 서브시스템을 포함하는 동일한 API 호출 세트를 단순히 적용하여 생성된 네트워크 부하는 새로운 요청의 수의 증가에 따라 선형적으로만 증가할 것이다. 사용자와 사용자가 생성하는 트랜잭션이 기하급수적으로 증가하는 것은 네트워크 부하가 기하급수적으로 증가하게 할 것이며, 이는 빠르게 네트워크에 큰 부담을 줄 수 있다. 따라서 네트워크 부하를 감소시키고 수요 증가를 충족하기 위해 확장성을 개선하려면, API 호출 세트가 최적화되어야 한다.
본 개시의 일 양태는 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 시스템에 관한 것이다. 이 시스템은 명령을 저장하도록 구성된 적어도 하나의 비일시적 컴퓨터-판독가능 매체; 및 동작들을 수행하기 위해 명령을 실행시키도록 구성된 적어도 하나의 프로세서를 포함할 수 있다. 동작들은 사용자 디바이스로부터 반품 아이템의 반품을 요청하는 반품 API(application programming interface) 호출을 수신하고; 네트워크 데이터베이스의 데이터 레코드에 대해 반품 API 호출을 검증하고; 반품 아이템이 복수의 개별 아이템을 포함한다고 결정하고; 개별 아이템의 서브세트가 결함이 있는지 여부를 결정하기 위해 반품 API 호출의 반품 코드를 분석하고; 개별 아이템의 서브세트에 상응하는 반품 아이템의 가격의 부분을 결정하고; 환불로서 반품 아이템의 가격의 부분을 발행하기 위한 환불 API 호출을 생성하고; 환불을 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고; 그리고 반품 API 호출의 승인에 관한 알림을 사용자 디바이스로 전송하는 것을 포함할 수 있다.
본 개시의 다른 양태는 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 방법에 관한 것이다. 이 방법은 사용자 디바이스로부터 반품 아이템의 반품을 요청하는 반품 API 호출을 수신하고; 네트워크 데이터베이스의 데이터 레코드에 대해 반품 API 호출을 검증하고; 반품 아이템이 복수의 개별 아이템을 포함한다고 결정하고; 개별 아이템의 서브세트가 결함이 있는지 여부를 결정하기 위해 반품 API 호출의 반품 코드를 분석하고; 개별 아이템의 서브세트에 상응하는 반품 아이템의 가격의 부분을 결정하고; 환불로서 반품 아이템의 가격의 부분을 발행하기 위한 환불 API 호출을 생성하고; 환불을 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고; 그리고 반품 API 호출의 승인에 관한 알림을 사용자 디바이스로 전송하는 것을 포함할 수 있다.
본 개시의 또 다른 양태는 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 시스템에 관한 것이다. 이 시스템은 명령을 저장하도록 구성된 적어도 하나의 비일시적 컴퓨터-판독가능 매체; 및 동작들을 수행하기 위해 명령을 실행시키도록 구성된 적어도 하나의 프로세서를 포함할 수 있다. 동작들은 사용자 디바이스로부터 아이템의 일부에 대한 반품을 요청하는 반품 API 호출을 수신하고; 아이템의 일부와 아이템 전체 간의 비율을 결정하기 위해 반품 API 호출을 파싱하고; 아이템의 일부와 연관된 카테고리 식별자를 반품 API 호출에 포함된 이유 코드와 비교하고; 만약 카테고리 식별자가 이유 코드에 대해 수용 가능하면: 환불 API 호출을 결제 관리 시스템으로 전송하고, 비율에 기초하여 환불을 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고, 그리고 반품 API 호출의 승인에 관한 알림을 사용자 디바이스로 전송하고; 그리고 만약 카테고리 식별자가 이유 코드에 대해 수용 가능하지 않으면: 아이템의 일부의 회수(retrieval)를 요청하는 회수 API 호출을 생성하고, 아이템의 일부가 회수되면 아이템의 일부의 아이템 식별자를 캡처하고, 아이템의 일부의 회수를 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고, 환불 API 호출을 결제 관리 시스템으로 전송하고, 비율에 기초하여 환불을 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고, 그리고 반품 API 호출의 승인에 관한 알림을 사용자 디바이스로 전송하는 것을 포함할 수 있다.
다른 시스템들, 방법들, 및 컴퓨터-판독 가능 매체도 본 명세서에서 논의된다.
도 1a는 개시된 실시예에 따른, 배송, 운송, 및 물류 운영을 가능하게 하는 통신을 위한 컴퓨터 시스템을 포함하는 네트워크의 예시적인 실시예를 나타낸 개략적인 블록도이다.
도 1b는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 회수 요청을 만족시키는 하나 이상의 검색 결과를 포함하는 검색 결과 페이지(SRP; Search Result Page)의 샘플을 나타낸 도면이다.
도 1c는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 제품 및 제품에 대한 정보를 포함하는 싱글 디테일 페이지(SDP; Single Detail Page)의 샘플을 나타낸 도면이다.
도 1d는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 가상의 쇼핑 장바구니에 아이템을 포함하는 장바구니 페이지의 샘플을 나타낸 도면이다.
도 1e는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라, 가상의 쇼핑 장바구니로부터 구매 및 배송에 관한 정보에 따른 아이템을 포함하는 주문 페이지의 샘플을 나타낸 도면이다.
도 2는 개시된 실시예에 따른, 개시된 컴퓨터 시스템을 활용하도록 구성된 예시적인 풀필먼트 센터의 개략적인 도면이다.
도 3a는 개시된 실시예에 따른, 인테이크(intake) 서브-시스템(300)의 예시적인 도해적 표현을 나타낸 도면이다.
도 3b는 개시된 실시예에 따른, 출력 서브-시스템(325)의 예시적인 도해적 표현을 나타낸 도면이다.
도 3c는 개시된 실시예에 따른, 제어 서브-시스템, 예시적인 반품 이벤트저장소, 예시적인 규칙 엔진, 및 예시적인 외부 데이터 소스의 예시적인 도해적 표현을 나타낸 도면이다.
도 3d는 개시된 실시예에 따른, 워크플로우 서브-시스템(375)의 예시적인 도해적 표현을 나타낸 도면이다.
도 4는 현재 개시된 실시예의 장점을 갖는 반품 처리를 위한 네트워크 환경(400)의 예시적인 도해적 표현을 나타낸 도면이다.
도 5는 개시된 실시예에 따른, 반품을 처리하기 위한 컴퓨터화된 프로세스의 예시적인 순서도를 나타낸 도면이다.
도 6은 개시된 실시예에 따른, 환불을 처리하기 위한 컴퓨터화된 프로세스의 예시적인 순서도를 나타낸 도면이다.
도 1b는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 회수 요청을 만족시키는 하나 이상의 검색 결과를 포함하는 검색 결과 페이지(SRP; Search Result Page)의 샘플을 나타낸 도면이다.
도 1c는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 제품 및 제품에 대한 정보를 포함하는 싱글 디테일 페이지(SDP; Single Detail Page)의 샘플을 나타낸 도면이다.
도 1d는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라 가상의 쇼핑 장바구니에 아이템을 포함하는 장바구니 페이지의 샘플을 나타낸 도면이다.
도 1e는 개시된 실시예에 따른, 상호 동작 사용자 인터페이스 요소에 따라, 가상의 쇼핑 장바구니로부터 구매 및 배송에 관한 정보에 따른 아이템을 포함하는 주문 페이지의 샘플을 나타낸 도면이다.
도 2는 개시된 실시예에 따른, 개시된 컴퓨터 시스템을 활용하도록 구성된 예시적인 풀필먼트 센터의 개략적인 도면이다.
도 3a는 개시된 실시예에 따른, 인테이크(intake) 서브-시스템(300)의 예시적인 도해적 표현을 나타낸 도면이다.
도 3b는 개시된 실시예에 따른, 출력 서브-시스템(325)의 예시적인 도해적 표현을 나타낸 도면이다.
도 3c는 개시된 실시예에 따른, 제어 서브-시스템, 예시적인 반품 이벤트저장소, 예시적인 규칙 엔진, 및 예시적인 외부 데이터 소스의 예시적인 도해적 표현을 나타낸 도면이다.
도 3d는 개시된 실시예에 따른, 워크플로우 서브-시스템(375)의 예시적인 도해적 표현을 나타낸 도면이다.
도 4는 현재 개시된 실시예의 장점을 갖는 반품 처리를 위한 네트워크 환경(400)의 예시적인 도해적 표현을 나타낸 도면이다.
도 5는 개시된 실시예에 따른, 반품을 처리하기 위한 컴퓨터화된 프로세스의 예시적인 순서도를 나타낸 도면이다.
도 6은 개시된 실시예에 따른, 환불을 처리하기 위한 컴퓨터화된 프로세스의 예시적인 순서도를 나타낸 도면이다.
이어서 첨부된 도면을 참조하여 자세하게 설명된다. 가능하면, 다음의 설명에서 같거나 유사한 부분에 대해 참조되도록 도면에서 같은 도면 부호가 사용된다. 여기에 몇몇 예시적인 실시예가 설명되지만, 변경, 조정 및 다른 구현도 가능하다. 예를 들면, 도면 내의 구성 및 스텝에 대해 교체, 추가, 또는 변경이 이루어질 수 있고, 여기에 설명된 예시적인 방법은 개시된 방법에 대해 스텝을 교체, 순서 변경, 제거 또는 추가함으로써 변경될 수 있다. 따라서, 다음의 자세한 설명은 개시된 실시예 및 예시로 제한되는 것은 아니다. 대신에 본 발명의 적절한 범위는 청구범위에 의해 규정된다.
본 개시의 실시예는 보다 능률화된 프로세스로부터 이익을 얻을 수 있는 전자 요청의 서브세트를 식별하여, 전체 네트워크에 대한 부하를 감소시키고 확장성을 개선시키도록 구성된 시스템 및 방법에 관한 것이다. 전통적 또는 기존 프로세스와 비교하여, 능률화된 프로세스는 네트워크 부하, 컴퓨팅 성능 및/또는 작업 시간과 같은 리소스를 더 적게 필요로 한다는 점에서 더 유리할 수 있다.
도 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는 제품을 오퍼하는 판매자의 리스트를 포함할 수 있다. 이 리스트는 최저가로 제품을 판매하는 것으로 오퍼하는 판매자가 리스트의 최상단에 위치하도록, 각 판매자가 오퍼한 가격에 기초하여 순서가 정해질 수 있다. 이 리스트는 또한 최고 순위 판매자가 리스트의 최상단에 위치하도록, 판매자 순위에 기초하여 순서가 정해질 수 있다. 판매자 순위는, 예를 들어, 약속된 PPD를 지켰는지에 대한 판매자의 과거 추적 기록을 포함하는, 복수의 인자에 기초하여 만들어질 수 있다. 외부 프론트 엔드 시스템(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)내의 하나 이상의 시스템과 상호작용할 수 있게 하는 컴퓨터 시스템으로서 구현될 수 있다. 예를 들면, 시스템(100)이 사용자가 아이템에 대한 주문을 할 수 있게 하는 시스템의 프레젠테이션을 가능하게 하는 실시예에서, 내부 프론트 엔드 시스템(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)는 임의의 할당된 프로세스(예를 들면, 트럭에서 내리기, 픽업 구역에서 아이템을 픽업하기, 리비닝 월(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), WMS(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)에 의해 소유, 임대 또는 운행될 수 있다.
도 3a는 인테이크(intake) 서브-시스템(300)의 예시적인 도해적 표현을 나타낸다. 인테이크 서브-시스템(300)은 소스 API(302)로부터의 통신의 초기 처리를 위해 지정될 수 있다. 소스 API(302)는 소비자, 배달원, 관리자 및/또는 판매자가 사용하도록 특별히 구성될 수 있는 다수의 API 중 어느 하나일 수 있다. 소스 API(302)는 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있으며, 통신 컴포넌트는 예를 들어 모바일 디바이스, 데스크탑 컴퓨터, 어댑터, 컨트롤러, 서버, 또는 API 통신을 송신 및/또는 수신할 수 있는 임의의 다른 디바이스이다. 일부 실시예에서, 인테이크 서브-시스템(300) 및/또는 인테이크 서브-시스템(300)의 컴포넌트는 (예를 들어, 도 3b-3d에 설명되는 것 같은) 다른 서브-시스템에 통신 가능하게 연결될 수 있다.
인테이크 서브-시스템(300)은 또한 소스 API(302)가 통신 가능하게 연결될 수 있는 다수의 엔드포인트 API(304)를 포함할 수 있다. 일부 실시예에서, 엔드포인트 API(304)는 단일 엔드포인트 API만일 수 있다. 엔드포인트 API(304)는 API 제공자(미도시)에 의해 관리될 수 있는 복수의 컨트롤러, 어댑터, 및/또는 다른 컴퓨팅 디바이스를 포함할 수 있다. 예를 들어, 엔드포인트 API(304)는 컨트롤러(306a), 컨트롤러(306b), 컨트롤러(306c), 컨트롤러(306d), 및/또는 컨트롤러(306e)와 같은 컨트롤러들의 조합에 의해 구현될 수 있다. 일부 실시예에서, 컨트롤러는 특정 엔티티(예를 들어, 판매자)에 대한 동작들을 처리하도록 지정될 수 있다. 컨트롤러는 하드웨어 디바이스 또는 소프트웨어 프로그램일 수 있으며, 이는 상이한 엔티티 간(예를 들어, 소스 API(302)와 데이터 집계기(312) 간의) 데이터플로우를 관리할 수 있다. 예를 들어, 컨트롤러는 플래시 컨트롤러, 애플리케이션 딜리버리 컨트롤러, 주 도메인(primary domain) 컨트롤러, 베이스보드 관리 컨트롤러 및/또는 세션 보더 컨트롤러일 수 있지만, 이것들로 제한되지 않는다. 일부 실시예에서, 소스 API(302)로부터의 통신은 통신과 연관된 소스에 기초하여 특정 엔드포인트 API 또는 컨트롤러로 보내질 수 있다. 예를 들어, API 제공자는 소스 API(302)로부터 통신을 수신할 수 있고 (예를 들어, 메시지 식별자, IP 주소, MAC 주소, 통신 포맷, 및/또는 다른 고유 식별자에 기초하여) 통신의 소스 및/또는 유형을 결정할 수 있다. 식별된 통신 소스 및/또는 통신 유형에 기초하여, API 제공자는 통신을 특정 컨트롤러로 보낼 수 있으며, 이 특정 컨트롤러는 특정 소스 및/또는 유형을 갖는 통신을 위해 구성될 수 있다. 추가 예시로서, API 제공자는 소스 API(302)로부터의 통신이 그것의 통신 소스로서 소비자 디바이스를 갖고 그것의 통신 유형으로서 반품 요청을 갖는다고 결정할 수 있고, 해당 통신을 엔드포인트 API(304)(예를 들어, 컨트롤러(306b))로 보낼 수 있으며, 이 엔드포인트 API(304)는 수신된 통신의 소스 및/또는 유형을 갖는 통신을 처리하도록 구성(예를 들어, 반품 요청 통신을 위해 구성) 되었을 수 있다.
인테이크 서브-시스템(300)은 또한 소스 API(302)로부터의 통신을 검증할 수 있고, 엔드포인트 API(304)에 통신 가능하게 연결될 수 있는 검증기(308)를 포함할 수 있다. 검증기(308)는 엔드포인트 API(304) 내에 (예를 들어, 컨트롤러의 일부로서) 존재하거나, 또는 엔드포인트 API(304)가 연결될 수 있는 서버와 같은 별도의 컴포넌트로 존재할 수 있다. 검증기(308)는 검증 프로세스(예를 들어, 소스 API(302)로부터 수신된 통신을 검증하기 위한 프로세스)를 수행하도록 구성된 다양한 컴포넌트(예를 들어, 모듈, 디바이스, 프로세서 등)를 포함할 수 있다. 예를 들어, 검증기(308)는 검증기 호출자, (예를 들어, 통신으로부터의 데이터를 리포맷하기 위한) 검증 전처리기, (예를 들어, 데이터에 대해 검증 작업을 수행하기 위한) 검증기 프로세서, (예를 들어, 검증된 데이터를 도 3c의 규칙 엔진(362)과 같은 다른 엔티티에 의해 이해가능한 포맷으로 리포맷하기 위한) 검증기 후처리기, 검증 관리자, 및/또는 (다른 서브-시스템에 메시지를 보낼 수 있는) 메시지 발행자를 포함할 수 있다.
인테이크 서브-시스템(300)은 또한 검증기(308)가 통신 가능하게 연결될 수 있는 예외 핸들러(310)를 포함할 수 있다. 예외 핸들러(310)는 검증기(308)의 일부일 수 있고, 또는 서버 또는 모바일 디바이스와 같은, 별개의 디바이스 또는 컴포넌트일 수 있다. 일부 실시예에서, 검증기(308)는 검증기(308)에 의해 결정되었을 수 있는, 통신의 검증 결과에 기초하여 예외 핸들러(310)로 통신을 보낼 수 있다. 예를 들어, 통신이 검증기(308)에 의해 구현된 적어도 하나의 규칙 또는 알고리즘을 실패하면, 검증자는 해당 통신을 예외 핸들러(310)로 보낼 수 있다. 일부 실시예에서, 예외 핸들러(310)는 통신에 실패한 적어도 하나의 규칙 또는 알고리즘에 기초하여 (예를 들어, 관리자 디바이스에 알람을 발행하는) 통신으로부터의 정보를, 리포맷, 분할, 파싱, 태그 및/또는 그렇지 않으면 재구성 또는 전송하도록 구성될 수 있다. 예외 핸들러(310)는 데이터 집계기(312) 및/또는 로깅 및 추적 모듈(314)에 통신 가능하게 연결될 수 있다.
인테이크 서브-시스템(300)은 또한 엔드포인트 API(304), 예외 핸들러(310), 및/또는 로깅 및 추적 모듈(314)과 같은 상이한 소스로부터의 데이터를 집계할 수 있는 데이터 집계기(312)를 포함할 수 있다. 데이터 집계기(312)는 서브-시스템(300)의 컴포넌트 및/또는 임의의 디바이스뿐만 아니라, 도 3b의 서브-시스템(325), 도 3c의 355 및 도 3d의 375를 포함하는 다른 시스템의 컴포넌트 및/또는 디바이스에 통신 가능하게 연결될 수 있다. 데이터 집계기(312)는 다른 목적을 갖는 디바이스(예를 들어, 검증기(308))의 일부일 수 있고, 또는 서버 또는 모바일 디바이스와 같은 별개의 디바이스 또는 컴포넌트일 수 있다. 일부 실시예에서, 데이터 집계기(312)는 데이터 집계 프로세스(예를 들어, 소스 API(302) 및/또는 예외 핸들러(310)와 같은 소스로부터의 데이터를 집계 및/또는 분석하기 위한 프로세스)를 수행하도록 구성된 다양한 컴포넌트(예를 들어, 모듈, 디바이스, 프로세서 등)를 포함할 수 있다. 예를 들어, 데이터 집계기(312)는 데이터 캐싱 컴포넌트, 데이터 집계기 컴포넌트, 데이터 변환 컴포넌트, 데이터 매핑 컴포넌트, 및/또는 서비스 라우터를 포함할 수 있다.
인테이크 서브-시스템(300)은 또한 통신(예를 들어, API 소스(302)로부터의 통신)과 연관된 데이터를 로그 및/또는 추적할 수 있는 로깅 및 추적 모듈(314)을 포함할 수 있다. 로깅 및 추적 모듈(314)은 다른 목적을 갖는 디바이스(예를 들어, 데이터 집계기(312))의 일부일 수 있고, 또는 서버 또는 모바일 디바이스와 같은 별개의 디바이스 또는 컴포넌트일 수 있다. 일부 실시예에서, 로깅 및 추적 모듈(314)은 데이터 집계 프로세스(예를 들어, 소스 API(302) 및/또는 예외 핸들러(310)와 같은 소스로부터의 데이터를 추적 및/또는 로깅하기 위한 프로세스)를 수행하도록 구성된 다양한 컴포넌트(예를 들어, 모듈, 디바이스, 프로세서 등)를 포함할 수 있다. 예를 들어, 로깅 및 추적 모듈(314)은 추적기(316) 및/또는 추적 분석기(318)를 포함할 수 있다.
추적기(316)는 API 소스(302), 검증기(308) 등으로부터의 통신과 연관된 데이터와 같은 데이터를 추적하는 기능을 수행할 수 있다. 일부 실시예에서, 추적기(316)는 추적 식별자 및/또는 범위 식별자를 통신과 연관된 데이터에 추가하도록 구성될 수 있다. 일부 실시예에서, 추적기(316)는 데이터를 추적 및/또는 로깅하는 위치, 유지해야 할 추적 및/또는 로그의 임계 개수, 데이터 포맷, 전송해야 할 식별자의 특정 조합, 및/또는 추적해야 할 특정 라이브러리에 대한 정의와 같은, 로깅 및 추적과 관련된 정의(예를 들어, 사용자-정의, 기계-정의, 및/또는 사용자-정의 및 기계-정의의 조합)을 유지할수 있다. 일부 실시예에서, 추적기(316)는 Spring Cloud Sleuth와 같은 기능 제공자의 양태를 구현할 수 있다.
추적 분석기(318)는 디바이스(예를 들어, 소스 API(302)를 구현하는 디바이스)로부터의 통신과 연관될 수 있는 추적 데이터 및/또는 로그 데이터와 같은 데이터를 분석하는 기능을 수행할 수 있다. 예를 들어, 추적 분석기(318)는 타이밍 데이터(예를 들어, 예외가 발생한 시간, 예외 빈도 등), 태그, 규칙 실패 데이터, 규칙 충족 데이터, 디바이스 식별자, 메시지 식별자, 및/또는 소스 API(302)와 연관된 임의의 데이터를 집계할 수 있다. 일부 실시예에서, 추적 분석기(318)는 추적 및/또는 로그 데이터의 시각적 표현(예를 들어, 통계적 및/또는 기계 학습 알고리즘 등에 의해 생성된 추천, 라인 다이어그램, 필터링가능한 데이터의 차트 등)을 생성할 수 있다. 일부 실시예에서, 추적 분석기(318)는 Zipkin과 같은 기능 제공자의 양태를 구현할 수 있다.
도 3b는 출력 서브-시스템(325)의 예시적인 도해적 표현을 나타낸다. 출력 서브-시스템(325)은 도 3d의 워크플로우 서브-시스템(375)의 출력을 처리하기 위해 지정될 수 있다. 출력 서브-시스템(325)은 처리된 출력을 도 3c의 외부 데이터 소스(370)에 전달할 수 있고, 도 3a의 로깅 및 추적 모듈(314) 및/또는 외부 서비스(339a-e)중 하나 이상에 의해 로그 및/또는 추적되도록, 처리된 출력을 전달할 수 있다. 출력 서브-시스템(325)은 소비자, 배달원, 관리자, 및/또는 판매자가 사용하도록 특별하게 구성될 수 있다. 출력 서브-시스템(325)은 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있다. 일부 실시예들에서, 출력 서브-시스템(325) 및/또는 출력 서브-시스템(325)의 컴포넌트는 (예를 들어, 도 3a-3d에 설명되는 것 같은) 다른 서브-시스템들에 통신 가능하게 연결될 수 있다.
출력 서브-시스템(325)은 도 3d의 워크플로우 서브-시스템(375)에 통신 가능하게 연결될 수 있는 다수의 Creturns Domains 모듈(327)을 포함할 수 있다. 일부 실시예에서, Creturns Domains 모듈(327)은 다양한 서비스(329a-d)를 포함할 수 있다. 도 3b에 도시된 것과 같이 서비스들의 예들은 취소 서비스(329a), 반품 서비스(329b), 교환 서비스(329c), 및/또는 양해(concession) 서비스(329d)를 포함할 수 있다. 서비스(329a-d)의 각각은 도 3d의 워크플로우 서브-시스템(375)에서 각각의 워크플로우 태스크로부터의 출력을 처리하는 역할을 할 수 있다. 예를 들어, 도 3d의 취소 프로세스 워크플로우(383a)는 출력을 취소 서비스(329a)로 전달할 수 있는 반면, 도 3d의 반품 프로세스 워크플로우(383b)는 출력을 반품 서비스(329b)로 전달할 수 있다. Creturns Domains 모듈(327)의 아키텍처는 필요에 따라 추가 서비스를 추가하도록 수정된다.
Creturns Domains 모듈(327)은 도 3a의 로깅 및 추적 모듈(314), 및/또는 외부 서비스 프록시 모듈(331)로 로깅 및 추적하면서, 처리된 정보를 도 3c의 외부 데이터 소스(370)에 전달한다. 외부 데이터 소스(370)로 전달된 정보는 도 3c를 참조하는 섹션에서 설명되는 것처럼 저장된다. 로깅 및 추적 모듈(314)로 전달된 정보는 도 3a를 참조하는 섹션에서 앞서 설명된 것처럼 로깅되고 처리된다.
출력 서브-시스템(325)의 일부인 외부 서비스 프록시 모듈(331)은 적절한 외부 서비스(339a-e)로의 추가 지시를 위해 Creturns Domains 모듈(327)로부터 처리된 출력을 수신할 수 있다. 출력 서브-시스템(325)은 서비스 프록시를 두 번 이상 초기화하는데 필요한 컴퓨팅 리소스와 시간을 소비하지 않고 동일한 서비스에 반복적으로 접속하기 위해, 외부 서비스 프록시 모듈(331)을 사용할 수 있다. 외부 서비스 프록시 모듈(331)은 Creturns Domains 모듈(327)과 외부 서비스(339a-e) 사이에서 소프트웨어 또는 하드웨어 시스템으로 구현될 수 있다. 외부 서비스 프록시 모듈(331)은 출력 서브-시스템(325)과 같은 기계에 또는 별도의 서버에 존재할 수 있다. 외부 서비스 프록시 모듈(331)은 소비자, 관리자, 및/또는 판매자가 사용하도록 특별하게 구성될 수 있다. 외부 서비스 프록시 모듈(331)은 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있다.
외부 서비스 프록시 모듈(331)은 또한 도 3d의 Creturn 워크플로우 시작기(381)로부터 직접 데이터를 수신할 수 있고 도 3d의 워크플로우 서브-시스템(375)에 통신 가능하게 연결될 수 있는, 외부 서비스 작업자(333)를 포함할 수 있다. 외부 서비스 작업자(333)는 외부 서비스 프록시 모듈(331) 내에 존재할 수 있고, 또는 서버와 같이 외부 서비스 프록시 모듈(331)이 접속될 수 있는 별개의 컴포넌트로 존재할 수도 있다. 외부 서비스 작업자(333)는 출력 처리를 수행하도록 구성된 다양한 컴포넌트(예를 들어, 모듈, 디바이스, 프로세서 등)를 포함할 수 있다. 예를 들어, 외부 서비스 작업자(333)는 Creturns Domains 모듈(327)에 의해 처리되지 않은 데이터를 처리할 수 있다.
외부 서비스 프록시 모듈(331)은 또한 외부 서비스 작업자(333)가 통신 가능하게 연결될 수 있는 외부 API 요청자(335)를 포함할 수 있다. 외부 API 요청자(335)는 외부 서비스 프록시 모듈(331)의 일부일 수 있고, 또는 서버 또는 가상 인스턴스와 같은 별개의 디바이스 또는 컴포넌트일 수 있다. 일부 실시예에서, 외부 서비스 프록시 모듈(331)은, Creturns Domanin 모듈(327) 또는 외부 서비스 작업자(333)에 의해 결정되었을 수 있는, 외부 서비스(339a-e) 중 어느 것으로 출력을 전달해야 하는지에 기초하여 외부 API 요청자(335)와 직접 통신을 할 수 있다. 예를 들어, 외부 서비스가 통신을 위해 API가 필요하였으면, 외부 API 요청자(335)는 요구된 외부 서비스와의 커넥션을 확립하기 위해 적절한 API 정보를 요청할 수 있다. 일부 실시예에서, 외부 API 요청자(335)는 외부 서비스에 의해 사용되는 적어도 하나의 규칙 또는 알고리즘에 기초하여 통신으로부터의 정보를, 리포맷, 분할, 파싱, 태깅, 및/또는 그렇지 않으면 재구성 또는 전송하도록 구성될 수 있다.
외부 서비스 프록시 모듈(331)은 또한 외부 서비스 작업자(333)가 통신 가능하게 연결될 수 있는 프로듀서(337)를 포함할 수 있다. 프로듀서(337)는 외부 서비스 프록시 모듈(331)의 일부일 수 있고, 또는 서버 또는 가상 인스턴스와 같은 별개의 디바이스 또는 컴포넌트일 수 있다. 프로듀서(337)는 토픽에 메시지를 게시하는데 사용된다. 토픽은 메시지를 포함하는 여러 파티션으로 나뉠 수 있다. 파티션의 각 메시지는 그것의 고유한 오프셋으로 할당 및 식별된다. 메시지 자체에는 게시할 토픽 및 파티션에 대한 정보를 포함하여, 데이터가 동일한 프로듀서로 서로 다른 토픽에 게시될 수 있다. 일부 실시예에서, 프로듀서(337)는 Kafka를 사용하여 구현될 수 있다.
외부 서비스 프록시 모듈(331)은 처리된 정보를 도 3a의 로깅 및 추적 모듈(314) 및/또는 외부 서비스(339a-e)에 전달할 수 있다. 로깅 및 추적 모듈(314)로 전달된 정보는 도 3a를 참조하는 섹션에서 앞서 설명된 것처럼 로깅되고 처리된다. 외부 서비스(339a-e)는 요청에 기초하여 동작을 시작한다. 도 3b에 도시된 서비스들의 예시는 주문 서비스(339a), 풀필먼트 서비스(339b), 배송 서비스(329c), 혜택(benefit) 서비스(339d) 및/또는 티켓 서비스(339e)를 포함할 수 있다. 서비스(329a-d)의 각각은 특정 작업의 시작을 담당할 수 있다. 예를 들어, 도 3d의 워크플로우 서브-시스템(375)이 교환 서비스(329c) 처리를 위해 출력을 전달하는 경우, 그것은 다수의 외부 서비스를 개시할 수 있다. 아이템의 교환은 새로운 아이템을 주문하기 위한 주문 서비스(339a)로의 출력(주문 명령은 공급자로부터 아이템을 구매하는 명령, 피커에게 해당 아이템을 준비하라고 알리는 명령, 아이템을 온라인 구매하는 명령, 3자 상점에 가서 그것을 가져오는 명령, 또는 아이템을 획득하는 것을 관리하는 다른 명령들을 포함할 수 있음)과, 반품 배송 라벨을 생성하기 위한 배송 서비스(339c)로의 출력, 및/또는 반품 아이템을 처리하기 위한 풀필먼트 서비스(325)로의 출력을 포함할 수 있다. 출력 서브-시스템(325)의 아키텍처는 필요에 따라 추가적인 외부 서비스를 추가하도록 수정될 수 있다.
도 3c는 개시된 실시예에 따른, 예시적인 제어 서브-시스템(350), 예시적인 반품 이벤트저장소(361), 예시적인 규칙 엔진(362), 및 예시적인 외부 데이터 소스(370)의 도해적 표현(355)을 나타낸다.
제어 서브-시스템(350)은 도 3a의 시스템(300), 도 3b의 325 및 도 3d의 375의 다양한 컴포넌트에 의해 사용되는 데이터를 생성, 업데이트, 유지 및/또는 관리하도록 구성될 수 있다. 예를 들어, 제어 서브-시스템(350)은 고객에 의한 반품을 관리(예를 들어, 고객에 의한 반품을 승인 및 거절하기 위한 규칙)하고, 반품 처리를 위한 워크플로우를 관리하고, 및/또는 특정 반품 이벤트를 저장하기 위한 파라미터를 생성, 업데이트 및/또는 수정하도록 구성될 수 있다.
도 3c에 도시된 바와 같이, 제어 서브-시스템(350)은 규칙 관리 모듈(351), 이벤트 관리 모듈(352), 및 워크플로우 관리 모듈(353)을 포함할 수 있다.
규칙 관리 모듈(351)은 고객에 의한 반품을 처리하기 위한 규칙을 관리하도록 구성될 수 있다. 예를 들어, 규칙 관리 모듈(351)은 고객에 의한 반품 요청을 거절하기 위한 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예를 들어, 규칙 관리 모듈(351)은 예를 들어 고객의 이전 반품(들)에 관한 데이터, 반품 요청에 관련된 통화 금액, 반품할 물품의 유형 등을 포함하는 다양한 파라미터에 기초하여 고객에 의한 반품 요청을 거절하기 위한 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예를 들어, 규칙 관리 모듈(351)은 고객이 과거에 미리 정해진 일수(예를 들어, 180일) 내에 반품을 위해 빈(또는 부분적으로 빈) 박스를 반품했으면(이는 고객이 시스템에 사기를 시도했을 수 있음을 나타낼 수 있음), 해당 고객의 반품 요청을 거절하는 규칙을 생성할 수 있다.
일부 실시예에서, 규칙 관리 모듈(351)은 제어 서브-시스템(350)의 사용자에 의한 입력에 기초하여 규칙을 생성 및/또는 수정하도록 구성될 수 있다. 예를 들어, 규칙 관리 모듈(351)은 반품 요청을 검증하기 위한 규칙의 하나 이상의 파라미터를 수정하고 그에 따라 해당 규칙의 파라미터를 수정하기 위한 입력을 사용자로부터 수신할 수 있다.
이벤트 관리 모듈(352)은 반품 이벤트저장소(361)에 저장된 이벤트를 생성, 수정 및/또는 관리하도록 구성될 수 있다. 예를 들어, 이벤트 관리 모듈(352)은 고객 또는 시스템에 의해 개시된 반품 요청에 대한 일련의 이벤트를 생성하고 해당 이벤트를 반품 이벤트저장소(361)에 저장한다. 예를 들어, 고객은 고객과 연관된 사용자 디바이스를 통해 주문 반품을 개시할 수 있다. 이벤트 관리 모듈(352)은 반품 요청을 수신하는 이벤트를 생성하고 해당 이벤트를 반품 이벤트저장소(361)에 저장할 수 있다. 일부 실시예에서, 이벤트는 반품, 고객, 및 반품과 연관된 주문과 관련된 정보를 포함할 수 있다. 예를 들어, 이벤트 관리 모듈(352)은 반품 요청의 정보, 반품 요청을 수신한 타임스탬프, 고객과 관련된 정보 등 또는 이들의 조합을 포함할 수 있는, 고객에 의해 요청된 반품에 대한 제1 이벤트를 생성할 수 있다. 이벤트 관리 모듈(352)은 반품 대상인 하나 이상의 아이템이 고객으로부터 수령될 때 제2 이벤트를 생성할 수 있으며, 여기에는 수신된 아이템(들)과 관련된 정보(예를 들어, 수량, 상태 등), 아이템(들)을 수령한 타임스탬프 등을 포함할 수 있다. 이벤트 관리 모듈(352)은 또한 제1 및 제2 이벤트를 해당 반품과 관련된 일련의 이벤트로서 반품 이벤트저장소(361)에 저장할 수 있다.
일부 실시예에서, 반품 이벤트저장소(361)는 예를 들어 Oracle™ 데이터베이스, Sybase™ 데이터베이스, 또는 다른 관계형 데이터베이스 또는 Hadoop™ 시퀀스 파일, HBase™ 또는 Cassandra™과 같은 비관계형 데이터베이스를 포함할 수 있다. 반품 이벤트저장소(361)는 HBase, MongoDB™ 또는 Cassandra™와 같은 NoSQL 데이터베이스를 포함할 수 있다. 대안적으로, 데이터베이스(320)는 Oracle, MySQL 및 Microsoft SQL Server와 같은 관계형 데이터베이스를 포함할 수 있다. 일부 실시예에서, 반품 이벤트저장소(361)는 서버, 범용 컴퓨터, 메인프레임 컴퓨터, 또는 이들 컴포넌트의 임의의 조합의 형태를 취할 수 있다.
워크플로우 관리 모듈(353)은 도 3a의 시스템(300), 도 3b의 325 및 도 3d의 375의 다양한 컴포넌트에 의해 사용되는 워크플로우를 생성, 수정 및/또는 관리하도록 구성될 수 있다. 예를 들어, 워크플로우 관리 모듈(353)은 워크플로우 서브-시스템(375)(도 3d에 도시됨)에 의해 사용되는 취소 프로세스(383a), 반품 프로세스(383b), 교환 프로세스(383c), 배송 추적(383d), 수거 프로세스(383e), 환불 프로세스(383f), 및 철회(withdraw) 프로세스(383g)를 생성, 수정 및/또는 관리하도록 구성될 수 있다.
일부 실시예에서, 제어 서브-시스템(350)은 Creturns Domains 모듈(327)(도 3b에 도시됨)에 의해 사용되는 서비스들을 생성, 수정 및/또는 관리하도록 구성될 수 있다. 예를 들어, 제어 서브-시스템(350)은 취소 서비스(329a), 반품 서비스(329b), 교환 서비스(329c), 및/또는 양해 서비스(329d)를 생성, 수정 및/또는 관리하도록 구성될 수 있다. Creturns Domains 모듈(327)은 제어 서브-시스템(350)으로부터 하나 이상의 서비스를 획득할 수 있다.
규칙 엔진(362)은 제어 서브-시스템(350)으로부터 반품을 처리하기 위한 규칙을 획득하고, 도 3d의 워크플로우 서브-시스템(375)의 다른 컴포넌트에 대한 규칙을 저장 및/또는 관리하도록 구성될 수 있다. 예를 들어, 도 3d의 워크플로우 서브-시스템(375)은 규칙 엔진(362)으로부터의 반품 요청을 검증하기 위한 규칙을 획득하도록 구성될 수 있다. 일부 실시예에서, 규칙 엔진(362)은 반품을 관리 및/또는 처리하기 위한 규칙을 저장하기 위한 규칙 데이터베이스(363)를 포함할 수 있다.
외부 데이터 소스(370)는 도 3a의 서브시스템(300), 도 3b의 325 및 도 3d의 375를 포함하는 시스템의 다양한 컴포넌트에 대한 데이터를 저장하도록 구성될 수 있다. 예를 들어, 외부 데이터 소스(370)는 예를 들어 취소 서비스(329a), 반품 서비스(329b), 교환 서비스(329c), 및/또는 양해 서비스(329d)를 포함하는, 제어 서브-시스템(350)에 의해 생성 및/또는 업데이트되는 다양한 서비스를 저장할 수 있다. Creturns Domains 모듈(327)은 외부 데이터 소스(370)로부터 하나 이상의 서비스를 획득할 수 있다.
다른 예로서, 외부 데이터 소스(370)는 이벤트(예를 들어, 반품 이벤트)와 관련된 데이터를 저장하도록 구성된 이벤트저장소(371)를 포함할 수 있다. 일부 실시예에서, 이벤트저장소(371)는 쓰기 명령에 응답하여 데이터를 기록하도록 구성된 쓰기 데이터베이스(372)를 포함할 수 있다. 이벤트저장소는 또한 쿼리 명령에 응답해서 오직 데이터를 판독하도록 구성된 하나 이상의 읽기 데이터베이스(373)(예를 들어, 읽기 데이터베이스(373A), 읽기 데이터베이스(373B) 등)를 포함할 수 있다. 일부 실시예에서, 읽기 데이터베이스(373)는 쓰기 데이터베이스(372)에 포함된 데이터와 동일한 데이터를 포함할 수 있다. 예를 들어, 쓰기 데이터베이스(372)에 저장된 데이터가 쓰기 명령에 응답하여 업데이트되면, 그에 따라 쓰기 데이터베이스(372)와 읽기 데이터베이스(373)가 동일한 데이터를 포함할 수 있도록, 읽기 데이터베이스에 상응하는 데이터가 업데이트될 수 있다. 일부 실시예에서, 외부 데이터 소스(370)는 제어 서브-시스템(350)에 대한 관리 데이터를 저장하도록 구성된 관리 데이터베이스(374)를 포함할 수 있다.
일부 실시예에서, 이벤트저장소(371) 및/또는 관리 데이터베이스(374)는 예를 들어, Oracle™ 데이터베이스, Sybase™ 데이터베이스, 또는 다른 관계형 데이터베이스, 또는 Hadoop™ 시퀀스 파일, HBase™ 또는 Cassandra™와 같은 비관계형 데이터베이스를 포함할 수 있다. 이벤트저장소(371) 및/또는 관리 데이터베이스(374)는 HBase, MongoDB™ 또는 Cassandra™와 같은 NoSQL 데이터베이스를 포함할 수 있다. 대안적으로, 데이터베이스(320)는 Oracle, MySQL 및 Microsoft SQL Server와 같은 관계형 데이터베이스를 포함할 수 있다. 일부 실시예에서, 이벤트저장소(371) 및/또는 관리 데이터베이스(374)는 서버, 범용 컴퓨터, 메인프레임 컴퓨터, 또는 이들 컴포넌트의 임의의 조합의 형태를 취할 수 있다.
도 3d는 워크플로우 서브-시스템(375)의 예시적인 도해적 표현을 나타낸다. 워크플로우 서브-시스템(375)은 인테이크 서브-시스템(300)의 출력을 처리하기 위해 지정될 수 있다. 워크플로우 서브-시스템(375)은 검증기(308) 출력을 출력 서브-시스템(325)으로 전달할 수 있다. 워크플로우 서브-시스템(375)은 소비자, 배달원, 관리자 및/또는 판매자가 사용하도록 특별하게 구성될 수 있다. 워크플로우 서브-시스템(375)은 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있다. 일부 실시예에서, 워크플로우 서브-시스템(375) 및/또는 워크플로우 서브-시스템(375)의 컴포넌트는 (예를 들어, 도 3a-3d에 설명되는 것 같은) 다른 서브-시스템에 통신 가능하게 연결될 수 있다.
워크플로우 서브-시스템(375)은 프레임워크 모듈(377)을 포함할 수 있다. 프레임워크 모듈(377)은 Spring WebFlux 또는 유사한 기술을 이용할 수 있다. 프레임워크 모듈(377)은 적은 수의 스레드와 더 적은 하드웨어 리소스 규모로 동시성을 처리하기 위해 비차단 웹 스택을 제공할 수 있다. 프레임워크 모듈(377)은 다양한 프로그래밍 모듈을 포함할 수 있다. 도 3d에 도시된 모듈들의 예시는 반품 모듈(379a), 교환 모듈(379b) 및 취소 모듈(379c)을 포함할 수 있다. 모듈(379a-c)은 소매, 3자 및 티켓 오퍼(offer)에 대한 프로세싱 로직을 포함할 수 있다. 모듈(379a-c)은 또한 각각의 데이터를 담당하는 서브-시스템과의 통신을 위한 API를 포함할 수 있다.
워크플로우 서브-시스템(375)은 또한 프레임워크 모듈(377)에 통신 가능하게 연결될 수 있는 워크플로우 시작기(381)를 포함할 수 있다. 워크플로우 시작기(381)는 프레임워크 모듈(377)로부터 수신된 입력에 기초하여 워크플로우를 개시할 수 있는 프로세스(383a-g)의 목록을 포함할 수 있다. 도 3d에 도시된 프로세스들의 예시는 (소비자, 공급자, 또는 다른 주문 핸들러에 의한 주문의 취소에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 취소 프로세스(383a), (소비자, 공급자, 또는 다른 주문 핸들러에 의한 전체 또는 부분 주문 반품에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 반품 프로세스(383b), (소비자, 공급자, 또는 다른 주문 핸들러에 의해 시작된 전체 또는 부분 주문의 교환에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 교환 프로세스(383c), (소비자, 공급자, 또는 다른 주문 핸들러에 의한 전체 또는 부분 주문의 배송 상태를 추적하라는 요청에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 배송 추적(383d), (소비자, 공급자, 또는 다른 주문 핸들러에 의한 전체 또는 부분 주문의 추적 정보에 대한 요청에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 수거 프로세스(383e), (소비자, 공급자, 또는 다른 주문 핸들러에 의해 시작된 전체 또는 부분 주문에 대한 환불 요청에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 환불 프로세스(383f), (소비자, 공급자, 또는 다른 주문 핸들러에 의해 시작된 전체 또는 부분 주문의 철회에 의해 개시되는 워크플로우를 시작하기 위한 명령을 포함하는) 철회 프로세스(383g)를 포함할 수 있다.
또한, 프레임워크 모듈(377)의 프로그래밍 모듈(379a-c)의 각각은 복수의 프로세스(383a-g)를 개시할 수 있다. 예를 들어, 취소 모듈(379c)은 취소되어 있는 아이템이 배송되었는지 또는 배송 직원이 아직 가지고 있는지를 결정하기 위해 배송 추적 프로세스(383d)를 개시할 수 있다. 동일한 취소 모듈(379c)은 또한 고객에게 환불을 발행하기 위해 환불 프로세스(383f)를 개시할 수 있다.
다양한 조합이 프로그래밍될 수 있고 소비자, 배달원, 관리자 및/또는 판매자가 사용하도록 특별하게 구성될 수 있다. 워크플로우 시작기(381)는 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있다. 일부 실시예에서, 워크플로우 시작기(381) 및/또는 워크플로우 시작기(381)의 컴포넌트는 (예를 들어, 도 3d에 설명된 바와 같이) 워크플로우 서브-시스템(375)의 다른 부분에 통신 가능하게 연결될 수 있다. 또한, 워크플로우 서브-시스템(375)의 아키텍처는 필요에 따라 추가 프로세스 및 프로그래밍 모듈을 추가하도록 수정될 수 있다.
워크플로우 서브-시스템(375)은 또한 워크플로우 시작기(381) 및 출력 서브-시스템(325)에 통신 가능하게 연결될 수 있는 워크플로우 서비스 모듈(385)을 포함할 수 있다. 워크플로우 서비스 모듈(385)은 워크플로우 제어 및 설계를 위해 지정될 수 있다. 워크플로우 서비스 모듈(385)은 Creturn 워크플로우 서비스 모듈(387) 및 워크플로우 조정 모듈(391)을 포함할 수 있다. 워크플로우 서비스 모듈(385)은 출력 서브-시스템(325)에 의한 처리를 위해 출력을 제공할 수 있다.
Creturn 워크플로우 서비스 모듈(387)은 워크플로우 시작기(381)로부터 수신된 입력에 기초하여 워크플로우를 제어할 수 있는 복수의 서브-모듈(389a-b)을 포함할 수 있다. 도 3d에 도시된 프로세스들의 예시는 소매 아이템의 반품을 위한 워크플로우를 설계 및/또는 제어할 수 있는 소매 반품 서브-모듈(389a)과, 3자 아이템의 반품을 위한 워크플로우를 설계 및/또는 제어할 수 있는 3자 반품 서브-모듈(389b)을 포함할 수 있다. Creturn 워크플로우 서비스 모듈(387)의 아키텍처는 필요에 따라 추가 서브-모듈을 추가하도록 수정될 수 있다. Creturn 워크플로우 서비스 모듈(387) 내의 워크플로우는 소비자, 배달원, 관리자 및/또는 판매자에 의해 제어 및/또는 설계될 수 있다. Creturn 워크플로우 서비스 모듈(387)은 프로세서, 메모리 컴포넌트 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있으며 워크플로우 서브-시스템(375)의 다른 부분에 통신 가능하게 연결될 수 있다.
워크플로우 조정 모듈(391)은 소비자, 배달원, 관리자 및/또는 판매자에 의해 액세스될 수 있는 워크플로우 제어 세트를 포함할 수 있다. 워크플로우 조정 모듈(391)은 비즈니스 프로세스 관리(BPM) 엔진 및 서포팅 프레임워크로 구현될 수 있으며, 그 중 하나는 Spring Boot/Docker를 사용한 Activiti일 수 있다. 워크플로우 조정 모듈(391) 엔진은, 인간 작업 및 서비스 호출로 구성되는 프로세스 정의를 가져와 그것들을 특정 순서로 실행시키는 것을 핵심 목표로 하며, 그 동안 해당 정의에 대한 프로세스 인스턴스에 대한 데이터를, 시작, 관리, 및 쿼리하기 위해 다양한 API를 노출시킨다. 워크플로우 조정 모듈(391)은 프로세서, 메모리 컴포넌트, 및/또는 통신 컴포넌트를 갖는 컴퓨팅 디바이스 상에 구현될 수 있다. 워크플로우 조정 모듈(391)은 워크플로우 서브-시스템(375)의 다른 부분에 통신 가능하게 연결될 수 있다.
도 4는 현재 개시된 실시예의 장점을 갖는 반품 처리를 위한 네트워크 환경(400)의 예시적인 도해적 표현을 나타낸다. 명료함과 추가 설명을 위해 도 3a-3d에 도시된 상이한 시스템, 서브시스템, 및 모듈의 서브세트만이 도시되어 있지만, 도 3a-3d의 다른 요소들이 네트워크 환경(400)에 포함될 수 있다. 또한, 이하에 개시되는 요소들의 구성 및 기능은 도 3a-도 3d에서 상응하는 요소들의 구성 및 기능과 결합될 수 있다.
일부 실시예에서, 소스 API(302)는 반품에 대한 전자 요청을 전송하도록 구성된 임의의 수의 API를 포함할 수 있다. 소스 API(302)의 각 API는 고객의 모바일 디바이스(102A) 또는 작업자가 고객으로부터의 반품 요청을 수동으로 등록하는데 사용할 수 있는 내부 고객 서비스 시스템과 같은 통신 디바이스에 상주할 수 있다. 이러한 디바이스를 사용하여, 예를 들어, 소스 API(302)는 API 호출을 엔드포인트 API(304)로 전송하는 고객의 모바일 디바이스에 설치된 모바일 애플리케이션, 유사한 API 호출을 전송하는 고객의 컴퓨터로부터 액세스되는 웹페이지, 수동으로 반품 요청을 입력하는 고객 서비스 에이전트의 컴퓨터로부터 동작하는 애플리케이션 등을 포함할 수 있다.
엔드포인트 API(304)는 이어 소스 API(302)로부터 API 호출을 수신하고 이를 네트워크 환경(400)의 적절한 시스템, 서브시스템, 및/또는 모듈로 라우팅할 수 있다. 일부 실시예에서, 엔드포인트 API는 수신된 API 호출을 더 조절(conditioning)하고 네트워크 환경(400)의 통신 프로토콜(예를 들어, 자바, HTML, CSS, 또는 다른 프로그래밍 언어)을 채택하기 위해 상술된 컨트롤러(306a-e)를 사용할 수 있다.
라우팅된 API 호출을 수신하는 엔티티 중 하나는, 일부 실시예에서, 검증기(308)일 수 있다. 검증기(308)는 예를 들어 모든 필수 정보가 존재하고 각 데이터 유형 및 포맷을 준수하는 것을 보장하기 위해, 라우팅된 API 호출에 포함된 데이터를 확인하도록 구성될 수 있다.
일부 실시예에서, 검증된 API 호출은 예를 들어 프레임워크 모듈(377)과 워크플로우 시작기(381)를 통해 워크플로우 서비스 모듈(385)로 전송될 수 있다. 워크플로우 서비스 모듈(385)은 API 호출에 의해 표현되는 각 요청에 적합한 다양한 동작를 취하는, 워크플로우 시작기(381) 내 상이한 프로세스(예를 들어, 반품 프로세스(383b) 또는 환불 프로세스(383f))에 의해 개시될 때 상이한 규칙에 기초하여 검증된 API 호출을 처리하도록 구성될 수 있다.
여기에 개시된 실시예에 따르면, 일부 규칙은 능률화된 프로세스에 적격한(eligible) 반품 요청 호출을 식별하는데 사용될 수 있다. 식별은 전체적으로 각 API 호출에 포함된 데이터를 고려하는 것에 기초할 수 있고, API 호출 내 상이한 파라미터의 값은 서로 조합되어 분석된다. 예를 들어, 워크플로우 서비스 모듈(385)은 고객-특정 코드, 반품될 아이템의 유형, 반품될 아이템의 가격, 고객의 과거 반품 이력, 판매자의 위치, 또는 반품 아이템과 상응하는 주문에 대한 아이템의 다른 양태 중 하나 이상을 분석할 수 있다.
일부 실시예에서, 워크플로우 서비스 모듈(385)에 의해 사용되는 규칙은 규칙 관리 모듈(351)에 저장될 수 있다. 도 3c와 관련하여 상술된 것처럼, 규칙 관리 모듈(351)은 각 반품 요청 호출에서 요청된 대로 반품을 처리하기 위한 규칙을 관리하도록 구성될 수 있다. 규칙 관리 모듈(351)은 규칙 데이터베이스(363)에 반품 적격성 기준 또는 능률화된 프로세스 적격성 기준과 같은 규칙들(또는 상응하는 비즈니스 로직)을 중앙화하여 저장하는 능력을 제공할 수 있는 규칙 엔진(362)을 통해, 규칙 엔진 기술을 활용할 수 있다. 이는 예를 들어, 새로운 고객 요구 사항, 규제 변경 사항 및/또는 마켓플레이스에서의 경쟁을 신속하게 충족할 수 있도록 하기 위해, 규칙이 쉽게 변경되는 것을 허용한다.
반품 요청 호출이 워크플로우 서비스 모듈(385)에 의해 처리되면(예를 들어, 반품 요청을 승인 또는 거부할지 여부가 결정되거나, 또는 반품 요청이 능률화된 프로세스에 적격인지 여부가 결정되면), 워크플로우 서비스 모듈(385)은 적합한 동작을 취하기 위해, 일련의 추가 API 호출을 생성하여 다른 시스템, 서브시스템 또는 모듈로 전송할 수 있다. 예를 들어, 워크플로우 서비스 모듈(385)이 반품 요청 호출이 승인되었다고 결정할 때, 워크플로우 서비스 모듈(385)은 풀필먼트 서비스(339b) 및/또는 배송 서비스(339c)를 활성화하기 위해 Creturns Domains 모듈(327)을 통해 외부 서비스 프록시(331)에 대한 호출을 생성할 수 있다. 승인된 반품 요청 호출이 거치는 프로세스는 도 5와 관련하여 후술된다.
도 5는 현재 개시된 실시예의 장점을 갖는, 반품을 처리하기 위한 예시적인 컴퓨터화된 프로세스(500)의 흐름도이다. 프로세스(500)가 반품 프로세싱에 적용되는 것으로 설명되지만, 이러한 사용은 단지 예시일 뿐이며 프로세스(500)는 네트워크 부하를 줄이고 확장성을 향상시키기 위해 다른 프로세스를 조정하도록 수정될 수 있다. 프로세스(500)는 임의 시스템, 시스템의 네트워크, 서버 또는 도 3a-3d와 도 4에 관련해서 상술되어진 시스템과 같은 반품을 처리하는 업무를 맡은 것으로 수행될 수 있다. 프로세스(500)는 도 4의 네트워크 환경(400)뿐만 아니라 도 3a-3d의 서브시스템을 참조하여 아래에서 설명되지만, 시스템, 서브시스템 또는 모듈의 임의의 다른 구성이 프로세스(500)를 수행하는데 사용될 수 있다.
프로세스(500)는 반품 요청을 검토하고 실행하기 위한 두 가지 예시적인 프로세스, 즉 반품을 관리(예를 들어, 요청을 수신하고 반품된 아이템을 수령하는 것)하는 것에 대한 정확성을 향상시키는 단계 501-506으로 표현되는 일반 프로세스와, 반품을 검토하고 실행하는 것에 대한 속도를 향상시키는 단계 501-503, 507 및 508로 표현되는 능률화된 프로세스를 나타낸다. 일부 실시예에서, 프로세스(500)의 두 프로세스는 도 3a-3b에 도시되고, 그것들의 서브세트가 도 4에도 도시되어 있는, 시스템, 서브시스템 및 모듈에 의해 수행될 수 있다. 두 프로세스의 변형도 개시된 실시예의 범위 내에 있으며, 프로세스(500)는 반품 요청을 검토하고 실행하기 위한 다른 프로세스도 포함할 수 있다.
단계 501에서, 하나 이상의 아이템을 반품하기 위한 반품 요청을 고객 디바이스로부터 수신함으로써 일반 프로세스가 개시될 수 있다. 일부 실시예에서, 반품 요청은 소스 API(302)에 의해 생성 및 전송된 반품 요청 호출일 수 있다. 예로서, 반품 요청은 고객이 이전에 주문해서 수령한 주문의 아이템 중 하나를 반품하기 위해 고객에 의해 생성될 수 있다. 일부 실시예에서, 엔드포인트 API(304)는 상술된 것과 같이 반품 요청 호출을 적절한 목적지로 라우팅할 수 있다.
일부 실시예에서, 고객은 부분 반품을 하는 옵션을 선택할 수 있는데, 이것은 다른 아이템들과 묶여 있었거나 일괄로 판매된 아이템(예를 들어, 3팩 휴대폰 화면 보호기)의 일부만이 반품되는 것이다. 이러한 선택은 소스 API(302)에 의해 상응하는 반품 요청 호출에 통합될 수 있으며, 여기서 소스 API(302)는 부분 반품을 위한 별도의 반품 요청 호출을 생성할 수 있다.
단계 502에서, 검증기(308)는 시스템 기록에 대해 반품 요청 호출을 검증할 수 있다. 예를 들어, 검증기(308)는 반품 요청 호출로부터 고객 정보, 반품될 아이템의 아이템 식별자, 아이템과 연관된 원래 주문의 주문 식별자와 같은 기본 정보를 추출하고, 해당 고객이 실제로 아이템을 주문한 사람이고 해당 아이템이 실제로 정확한 수량으로 주문에 포함된 아이템인지를 검증하기 위해 FO 시스템(113)에서 정보를 조회할 수 있다. 일부 실시예에서, 검증기(308)는 또한 아이템이 반품에 적격인지 여부를 결정하기 위해, 추출된 정보를 사용할 수 있다. 그러한 규칙은 상술된 규칙 관리 모듈(351)에 저장된 규칙의 일부일 수 있다.
반품 요청 호출이 부분 환불을 위한 것인 또 다른 실시예에서, 검증기(308)는 해당 아이템이 부분적으로 반품될 수 있는지 검증하기 위해 FO 시스템(113)에 질의할 수 있다. 검증은 부분 반품을 위한 아이템의 아이템 식별자를 부분 반품에 적합한 아이템 식별자의 미리 결정된 목록과 비교하거나 또는 다양한 요인에 기초하여 아이템의 적격성을 결정하는 것을 포함할 수 있다. 예를 들어, 요인들은 상응하는 벤더가 부분 반품을 수락할 것이라고 표시했는지 여부, 아이템의 일부를 별도로 판매할 수 있는지 여부, 일부가 다른 아이템과 함께 재포장 또는 재묶음될 수 있는지 여부, 또는 부분적 반품 아이템의 시장성에 영향을 미칠 수 있는 기타 요인들을 포함할 수 있다.
단계 503에서, 워크플로우 서비스 모듈(385)은 능률화된 프로세스에 대한 적격성을 결정하기 위해 반품 요청 호출을 분석할 수 있다. 단계 503은 능률화된 프로세스와 관련하여 아래에서 더 자세히 설명된다. 프로세스(500)가 일반 프로세스 또는 능률화된 프로세스 중 하나만을 포함하는 일부 실시예에서, 단계 503은 다른 기능을 수행하기 위해 생략되거나 대체될 수 있다. 추가 실시예에서, 단계 503은 또한 상술된 Creturn 워크플로우 서비스 모듈(387), 소매 반품 서브-모듈(389a), 3자 반품 서브-모듈(389b), 및 워크플로우 조정 모듈(391)과 같은 다양한 모듈을 사용하여 반품 요청을 승인할지 여부를 결정하는 것을 포함할 수 있다.
단계 504에서, 워크플로우 서비스 모듈(385)은 일련의 API 호출을 생성하여 다른 시스템, 서브시스템 또는 상술된 바와 같은 Creturns Domain(327), 외부 서비스 프록시(331), 풀필먼트 서비스(339b) 및 배송 서비스(339c)와 같은 모듈로 전송할 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 반품될 아이템의 회수를 요청하기 위해, 예를 들어, 반품 배송 라벨을 생성하거나 또는 고객으로부터 아이템을 픽업하기 위해 택배를 발송하는 것을 포함할 수 있는 하나 이상의 API 호출을 생성할 수 있다. 추가적 또는 대안적으로, 하나 이상의 API 호출은 자율 로봇, 차량 또는 드론과 같은 자율 시스템이 상응하는 반품 요청 호출에 특정된 고객의 주소로 이동하게 할 수 있고, 아이템을 회수하게 할 수도 있다.
또 다른 실시예에서, 단계 504는 풀필먼트 센터에서 반품 아이템을 수령하고 재입고하는 것을 포함할 수 있으며, 이 또한 자율 로봇, 차량 등을 사용하여 수행될 수 있다. 예를 들어, 단계 504는 (예를 들어, 카메라, 스캐너, RFID 센서 등을 사용하여) 풀필먼트 센터에 도착할 때 반품 아이템의 아이템 식별자를 캡처하고, 아이템의 회수 또는 도착을 기록하기 위해 외부 데이터 소스(370)의 데이터 레코드를 업데이트하는 것을 포함할 수 있다.
도 3b와 관련하여 상술되어진 것처럼, 아이템을 회수하고 재입고하는 것은 API 호출을 사용하여 각각 통신하는 모듈들의 복잡한 네트워크를 포함할 수 있다. 예를 들어, 반품 서비스(329b)는 다운스트림 모듈(예를 들어, 외부 서비스 프록시(331) 또는 서비스(339a-e)의 요소)에 대해 일련의 후속 호출을 트리거하는 워크플로우 서비스 모듈(385)로부터의 출력을 수신할 수 있으며, 일련의 후속 호출 각각은 아이템이 회수 및 재입고될 때 해당 아이템에 대한 고객 주소로부터 풀필먼트 센터(예를 들어, FC(200)) 내의 다양한 위치로의 물리적 이동과 연관된다.
단계 505에서, 반품 아이템이 풀필먼트 센터(예를 들어, FC(200))에서 수령되면, 출력 서브-시스템(325)은 반품 아이템의 가격에 대한 환불을 요청하기 위해 API 호출의 또 다른 세트를 생성할 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 환불을 위한 API 호출 세트를 생성하고 그 API 호출 세트를 금융 기관과의 통신 및 최종적인 결제 취소를 위해 결제 관리 시스템(도시되지 않음)으로 전송할 수 있다. 환불을 위한 API 호출은 또한 외부 데이터 소스(370)가 반품을 요청한 고객과 관련되는 데이터 레코드를 업데이트하도록 프롬프트할 수 있다.
이에 더하여, 단계 506에서, 출력 서브-시스템(325)은 알림(예를 들어, 문자 메시지, 인앱 푸시 알림, 이메일 등)을 생성하고 그 알림을 반품을 요청한 고객과 연관된 고객 디바이스로 전송할 수 있다. 이러한 알림은 환불을 위한 API 호출의 완료에 대한 응답하여 전송될 수 있다. 일부 실시예에서, 고객 디바이스는 위의 단계 501에서 초기에 반품 요청 호출을 전송한 디바이스일 수 있다. 추가적 또는 대안적으로, 고객 디바이스는 고객의 로그인 크리덴셜을 사용하여 인증된 상이한 디바이스일 수 있다.
상이한 시스템, 서브시스템 및 모듈의 네트워크 사이에서 API 호출의 교환이 복잡해 보일 수 있지만, 이러한 교환은 상이한 기능 유닛(즉, 서브-시스템 또는 모듈)이 특정 작업에 특화되도록 할 수 있다. 이를 통해 기존의 반품 관리 프로세스에 비해 효율성을 향상시키고 오류율을 줄일 수 있다. 일부 실시예에서, 상이한 작업의 이러한 구획화된(compartmentalized) 핸들링은 각각의 서브-시스템 또는 모듈의 모듈식 구현을 가능하게 할 수 있으며, 이는 또한 서브-시스템 또는 모듈 중 임의의 것이 실패할 때 유연성을 향상시킬 수 있게 하여, 네트워크의 다른 부분이 자체적으로 기능하게 할 수 있다.
반면에, 능률화된 프로세스는 반품을 위해 아이템을 회수하고 재입고하는 것과 같은, 일반 프로세스에서 수행되는 단계들의 일부를 생략함으로써 반품을 관리하는 속도를 향상시킬 수 있다. 일반 프로세스는 반품을 관리하는 것에 대한 효율성과 정확성을 향상시킬 수 있지만, 상술한 것과 같이 각 반품 요청 호출에 응답하여 상이한 서브-시스템과 모듈 간에 교환되는 각 API 호출은 시스템, 서브시스템 및 모듈의 네트워크에 부하를 준다. 부하가 아무리 작더라도, 해당 부하는 반품 요청 호출의 수가 증가함에 따라 빠르게 축적되어 네트워크를 압박하거나 압도할 수 있다.
예를 들어, 시스템이 반품 요청 호출을 처리하고 추적하는 동안, 하루 동안 배송 서비스(339c)로 반품 요청당 10개 이상의 API 호출이 생성될 수 있다. 10개 이상의 API 호출 각각은 또한 도 1a와 관련하여 상술되어진 다른 네트워크 시스템(예를 들어, SAT 시스템(101)) 내 일련의 후속 호출을 트리거할 수 있고, 이로써 네트워크 부하를 증가시킨다. 전체적으로, 단계 504가 프로세스(500)를 통한 반품을 처리하는데 소비되는 리소스의 대부분을 차지할 수 있다.
능률화된 프로세스는 반품 요청 호출의 서브세트에 대한 이러한 API 호출의 필요성을 제거하고, 이로써 네트워크 부하를 감소시킨다. 능률화된 프로세스에 의해 실현되는 절감은 개별 반품 요청 호출에 대해서는 무시할 수 있지만, 수십만 또는 수백만명의 사용자와 그들의 요청 사이에서 실현된 절감은 네트워크 확장성을 향상시키는 상당한 이점을 축적할 수 있다. 다시 말해서, 능률화된 프로세스를 통한 반품 요청 호출 처리로 인한 네트워크 리소스 감소는 사용자의 수와 그들의 요청이 기하급수적으로 증가하더라도 낮은 대기 시간과 최적의 네트워크 활용성을 보장할 수 있다. 이러한 절감은 결국 네트워크를 유지 관리하고 운영하는 측면에서 운영 비용을 더 낮추는데 기여할 수 있다.
이에 더하여, 능률화된 프로세스는 또한 일반 프로세스에 필요한 실제 인력과 물리적 리소스 측면에서 운영 비용을 절감할 수 있다. 예를 들어, 단계 504가 고객으로부터 반품 아이템을 회수하는 것을 포함하는 경우, 작업자가 고객의 주소로 파견되어, 반품 아이템을 확보하고 돌아와야 한다. 만약 고객이 부재 중이면 작업자가 다시 파견되어야 하는, 여러 번의 이동이 또한 필요할 수 있다. 또 다른 예시로, 반품 아이템을 검사하고 재입고하는 비용이 발생하는데, 이는 반품 아이템이 손상되거나 또는 환경 규정에 따라 폐기해야 하는 경우 일반 프로세스를 더욱 복잡하게 만들 수 있다. 따라서 능률화된 프로세스는 적격한 반품 요청의 서브세트에 대하여 일반 프로세스에 비해 기술 및 비즈니스 이점을 모두 제공한다.
부분 반품을 가능하게 하면 대형 반품을 소형 반품으로 쪼갬으로써 이러한 기술 및 비즈니스 이점에 더 기여할 수 있다. 예를 들어, 기존 반품 프로세스는 전체 반품만을 허용할 수 있는데, 여기서 각 아이템은 해당 아이템이 더 작은 아이템 그룹으로 구성되어 있는지 여부에 관계없이 전부 반품되어야 한다. 전체 아이템의 일부만이 반품될 필요가 있는 경우에도 고객에게 전체 아이템을 반품하도록 강제하는 것은, 전체 아이템의 일부가 능률화된 프로세스에 적격일 수 있기 때문에, 네트워크 환경(400)이 능률화된 프로세스를 최대한 활용하는 것을 방해할 수 있다. 전체 아이템 대신 아이템의 일부를 반품할 수 있도록 반품 요청의 최소 크기를 쪼개는 것은, 능률화된 프로세스의 적격 기준을 충족하기 위해 더 많은 반품 요청 호출을 허용할 수 있으므로, 네트워크 리소스 및 운영 비용을 감소를 증가시킨다.
단계 501-503, 507 및 508로 표현되는 능률화된 프로세스로 돌아가면, 프로세스는 일반 프로세스와 단계 501-503을 공유할 수 있다. 이러한 실시예에서, 모든 반품 요청 호출은 상술된 일반 프로세스 또는 아래에서 설명될 능률화된 프로세스 중 하나로 나뉘기 전에 단계 501 및 502를 거칠 수 있다.
단계 503에서, 워크플로우 서비스 모듈(385)은 능률화된 프로세스에 대한 적격성을 결정하기 위해 반품 요청 호출을 분석할 수 있다. 결정은 규칙 관리 모듈(351)에 저장된 규칙 세트에 기초할 수 있다. 일부 실시예에서, 규칙은 반품 요청 호출이 속하는 하나 이상의 상이한 시나리오에 상응할 수 있다. 예시적인 시나리오가 아래에 설명되어 있으며, 다른 시나리오 또는 그것들에 대한 변형도 개시된 실시예의 범위 내에 있다.
초기 문제로서, 일부 반품 요청 호출은 상응하는 주문이 고객에게 배송되기 전에 수신되었을 수 있다. 이와 같이, 워크플로우 서비스 모듈(385)은 상응하는 주문이 배송되었는지 여부를 확인하도록 구성될 수 있다. 워크플로우 서비스 모듈(385)은 FO 시스템(113)에 대해 상응하는 주문 식별자를 갖는 API 호출을 생성하고 주문의 상태를 수신함으로써 이것을 달성할 수 있다. 워크플로우 서비스 모듈(385)은 이어 주문을 전체적으로 또는 부분적으로 취소하고, 주문이 아직 배송되지 않으면 위에서 논의된 바와 같이 환불 요청을 생성하거나, 그렇지 않으면 반품 요청 호출이 능률화된 프로세스에 적격인지 여부를 결정하는 것으로 진행할 수 있다. 취소되지 않은 주문의 모든 부분은 상술된 주문 이행 프로세스의 다음 단계로 진행할 수 있다.
일부 실시예에서, 하나 이상의 규칙은 반품을 요청하는 이유를 나타내기 위한 고객-특정 코드에 기초하여 적격성을 결정할 수 있다. 고객-특정 코드는 예를 들어 고객이 모바일 애플리케이션 또는 웹사이트를 통해 반품 요청을 제출함으로써 특정될 수 있으며 파라미터로서 상응하는 반품 요청 호출에 포함될 수 있다. 고객-특정 코드는 상이한 시나리오와 연관된 미리 결정된 영숫자 문자열의 임의 세트를 포함할 수 있다. 가능한 시나리오는 예를 들어 변심, 잘못된 아이템, 운송 중 손상, 아이템 설명과 불일치, 없어진(missing) 아이템 등을 포함할 수 있다.
일부 실시예에서, 아이템이 애초에 없어서(예를 들어, 분실(lost) 또는 미배달되어) 고객이 해당 아이템을 물리적으로 반납할 수 없기 때문에, 없어진 아이템과 연관된 고객-특정 코드를 포함하는 반품 요청 호출은 능률화된 프로세스에 대해 적격한 것으로 설정될 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 또한 반품될 아이템에 상응하는 아이템 식별자를 능률화된 프로세스에 대해 적격한 아이템들의 목록과 비교할 수 있다. 대안적 또는 추가적으로, 상이한 시나리오와 연관된 다른 코드도 원하는 비즈니스 관행에 의해 결정되는 것처럼 능률화된 프로세스에 대해 적격한 것으로 설정할 수 있다.
이에 더하여, 워크플로우 서비스 모듈(385)은 고객이 사기 의도로 없어진 아이템에 대한 이유 코드를 선택할 수 있었는지 여부를 검증하기 위해 반품을 요청한 고객과 연관된 기록을 조회할 수 있다. 이러한 결정은 각 고객의 구매 및 반품 활동에 대한 상세 로그를 유지하고 있는 사기 검출 시스템(도시되지 않음)에 의해 수행될 수 있다. 사기 검출 시스템은 이어 의심스러운 요청을 식별하기 위해 기계 학습 알고리즘으로 로그를 분석할 수 있다. 예를 들어, 로그는 고객이 구매한 아티엠의 종류, 그것의 가격, 반품된 아이템들의 서브셋, 반품 아이템의 가격 및 상태, 또는 고객의 반품 요청에 직접 또는 간접적으로 포함된 기타 정보를 추적할 수 있다. 추가로 또는 대안적으로, 워크플로우 서비스 모듈(385)은 아이템의 구매 가격이 미리 결정된 임계값보다 크면 없어진 아이템과 연관된 고객-특정 코드를 포함하는 반품 요청 호출을 부적격으로 설정할 수 있다. 이것은 반품 요청 호출이 일반 프로세스를 거치기 때문에 워크플로우 서비스 모듈(385)이 반품 요청 호출을 더 철저하게 검토하고, 임의의 사기성 요청을 식별할 수 있게 한다.
단계 503으로 돌아가면, 다른 규칙 세트는 고객이 이미 풀필먼트 센터로 아이템을 배송했음을 나타내는 반품 요청 호출에 포함된 정보에 기초하여 적격성을 결정할 수 있다. 정보는 예를 들어 상술된 고객-특정 코드 및/또는 반품 배송에 대한 추적 번호 중 하나를 포함할 수 있다. 그러한 경우에, 워크플로우 서비스 모듈(385)은 단계 504와 관련하여 상술된 것과 같은 회수 요청을 생성할 필요가 없다고 결정할 수 있고, 상응하는 반품 요청 호출이 능률화된 프로세스에 적격이라고 결정할 수 있다. 워크플로우 서비스 모듈(385)은 또한 고객 자신의 반품 배송에 대한 정보를 포함하도록 고객에 의해 반품되어질 특정 아이템과 연관된 레코드를 업데이트하기 위한 API 호출을 생성 및 전송할 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 단계 507 및 508과 관련하여 상술된 방식으로 환불 요청을 생성하고 고객 디바이스로 알림을 전송하도록 진행할 수 있다.
추가 실시예에서, 또 다른 규칙 세트는 반품 아이템의 유형에 기초하여 능률화된 프로세스에 대한 적격성을 결정할 수 있다. 적격 유형은 예를 들어 재판매 가능한 상태로 풀필먼트 센터에 도착하지 않을 부패하기 쉬운 아이템 또는 상대적으로 높은 반품 배송비가 발생할 수 있는 외국 벤더로부터 구매한 아이템이 포함될 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 반품 요청 호출에 포함된 아이템 식별자를 갖는 연결된 데이터베이스(예를 들어, 외부 데이터 소스(370))에 전자 쿼리를 전송하고 아이템 유형에 대한 파라미터를 수신함으로써 아이템 유형을 결정할 수 있다.
연결된 데이터베이스는 권장 보관 온도와 함께 아이템 식별자 목록을 유지하고 상응하는 보관 온도에 기초한 적격성 결정으로 전자 쿼리에 응답하도록 구성될 수 있다. 예를 들어, 권장 보관 온도가 영하 이하인 아이템은 운송 중에 부패할 가능성이 있으므로 부적격으로 간주될 수 있다. 또 다른 실시예에서, 연결된 데이터베이스 내 아이템 식별자 목록은 아이템 중 일부가 외국 벤더에 의해 판매되었는지 여부를 명시할 수 있다. 상응하는 아이템을 회수하여 해당 외국 벤더에게 다시 배송하는 비용이 너무 커서 경우에 따라 해당 아이템을 회수하지 않는 것이 나을 수 있다. 이와 같이, 연결된 데이터베이스는 아이템들의 구매 가격이 미리 결정된 임계값보다 낮으면 해당 아이템들은 능률화된 프로세스에 대해 적격(따라서 해당 아이템을 회수하지 않고 구매 가격을 환불함)이라고 결정할 수 있다.
워크플로우 서비스 모듈(385)이 반품을 위한 아이템의 유형이 아이템 유형의 미리 결정된 세트 중 하나와 일치한다고 결정하면, 워크플로우 서비스 모듈(385)은 또한 상응하는 반품 요청 호출이 능률화된 프로세스에 적격이라고 결정할 수 있다. 일부 실시예에서, 이는 반품 아이템이 아마도 재판매 가능하지 않고 또는 수익성이 없어서, 단계 504와 관련하여 상술된 것과 같은 회수 요청을 생성할 필요가 없기 때문일 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 단계 507과 508과 관련하여 상술된 방식으로 환불 요청을 생성하고 고객 디바이스로 알림을 전송하는 것으로 다시 진행할 수 있다.
일부 실시예에서, 능률화된 프로세스에 적격인 반품을 요청한 고객들의 기록은 해당 고객이 아이템을 반품하지 않고 환불을 받을 자격이 있음을 반영하도록 업데이트될 수 있다. 이러한 기록은 나중에 반품없는 다른 환불에 적격한 것으로 보이는 사기성 반품 요청 호출을 분석하고 식별하기 위해 사기 검출 시스템(도시되지 않음)에 의해 사용될 수 있다.
단계 507에서, 워크플로우 서비스 모듈(385)이 반품 요청 호출이 능률화된 프로세스에 적격하다고 결정하면, 워크플로우 서비스 모듈(385)은 단계 505와 관련하여 상술된 것과 같은 환불 요청으로 진행할 수 있다. 그러나, 환불 요청이 반품 아이템을 수령하는 것에 응답하는 것인 단계 505와 대조적으로, 워크플로우 서비스 모듈(385)은 상응하는 반품 요청 호출이 능률화된 프로세스에 적격하다고 결정되면 환불 요청에 대한 API 호출을 생성할 수 있다.
대안적 또는 추가적으로, 워크플로우 서비스 모듈(385)은 환불을 발행하기 전에 사기성 반품 요청을 식별하기 위해 추가 검사를 수행할 수 있다. 워크플로우 서비스 모듈(385)은 상응하는 반품 요청 호출 및 고객에 대한 정보를 갖는 API 호출을 사기 감지 시스템에 전송할 수 있고, 이에 응답하여 사기 감지 시스템은 반품 요청 호출이 사기일 수 있는지에 대한 결정을 반환할 수 있다. 긍정적인 결정은 워크플로우 서비스 모듈(385)이 환불 요청을 거절하고 단계 504부터 시작하는 일반 프로세스 하에서 반품 요청 호출을 처리하게 할 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 또한 배송 서비스(339c)에 반품된 아이템이 없을 것임을 알리고, 단계 508에서, 단계 506과 관련하여 상술된 것과 같이 고객 디바이스로 알림을 전송한다.
도 6은 환불을 처리하기 위한 컴퓨터화된 프로세스(600)의 예시적인 흐름도를 나타낸다. 프로세스(600)는 일반 프로세스의 단계 505와 능률화된 프로세스의 단계 507에서 생성된 환불 요청을 포함하지만 이에 제한되지 않는, 상술된 시스템에 의해 생성된 임의의 환불 요청과 관련하여 수행될 수 있다. 프로세스(600)는 임의의 시스템, 시스템의 네트워크, 서버, 또는 도 3a-3d 및 도 4와 관련하여 상술된 시스템과 같은, 환불 처리를 담당하는 기타 시스템으로 수행될 수 있다. 프로세스(600)는 도 4의 네트워크 환경(400)뿐만 아니라, 도 3a-3d의 서브시스템을 참조하여 아래에서 설명되지만, 시스템, 서브시스템 또는 모듈의 임의의 다른 구성이 프로세스(600)를 수행하기 위해 사용될 수 있다.
단계 601에서, 워크플로우 시작기(381)는 하나 이상의 아이템의 구매 가격을 환불하라는 환불 요청을 수신함으로써 환불 프로세스를 시작할 수 있다. 환불 요청은 워크플로우 서비스 모듈(385)에 의해 생성되어 전송되는 API 호출의 형태일 수 있다. 일부 실시예에서, 단계 601은 환불 프로세스(383f)를 통해 환불 요청을 환불 요청 큐에 추가하는 것을 더 포함할 수 있다. 환불 요청은 환불이 구매 가격의 전체 환불인지 또는 그 일부인지를 명시하는 하나 이상의 파라미터를 포함할 수 있다.
단계 602에서, 워크플로우 서비스 모듈(385)은 정확한 환불 금액을 계산하기 위해, 해당 주문을 식별하기 위한 정보를 갖는 요청을 혜택 서비스(339d)에 송신하여 혜택 데이터를 수신할 수 있다. 혜택 데이터는 상응하는 고객이 구매시 제공받은 할인 및 프로모션에 대한 정보를 포함할 수 있다. 할인 및 프로모션은 벤더, 온라인 소매업체, 온라인 마켓플레이스 플랫폼, 결제 프로세서, 은행 등과 같은 다양한 엔티티에 의해 제공되었을 수 있다. 일부 실시예에서, 워크플로우 서비스 모듈(385)은 주문 서비스(339a)를 통해 이러한 데이터를 결제 처리 모듈(도시되지 않음)로 전송할 수 있다.
환불 요청이 부분 환불에 대한 것인 일부 실시예에서, 워크플로우 서비스 모듈(385)은 고객에 의해 구매된 아이템의 총 수량에 대한 환불을 위한 아이템들의 수량에 비례하는 환불 금액을 계산하기 위해, 환불 요청으로부터의 정보를 사용할 수 있다. 또 다른 실시예에서, 상응하는 주문 정보 또는 혜택 데이터에 기록될 수 있는 소정 아이템은, 구매해야 하는 아이템의 최소 개수를 요구하는 프로모션하에서 판매되었을 수 있다. 워크플로우 서비스 모듈(385)은 적어도 남아 있는 아이템의 개수가 해당 최소 개수 미만인지 여부에 기초하여, 이러한 아이템에 대한 환불 금액을 증가 또는 감소시킬 수 있다. 추가적 또는 대안적으로, 워크플로우 서비스 모듈(385)은 환불이 고객의 귀책(예를 들어, 너무 많이 주문, 변심 등)으로 인한 경우, 위약금 또는 수수료를 반영하기 위해 승수(multiplier)로 환불 금액을 조정할 수 있다.
단계 603에서, 결제 처리 모듈은 상응하는 주문의 결제 상태와 주문 상태를 업데이트할 수 있으며, 이는 환불 후 총 결제 금액 및 반품되어진 아이템을 반영하도록 하나 이상의 네트워크 데이터베이스에 상응하는 기록을 업데이트하는 것을 포함할 수 있다.
단계 604에서, 결제 처리 모듈은 주문 상태를 업데이트하면서 상응하는 정보를 검색함으로써 고객에 의해 이전에 행해진 결제 유형을 확인할 수 있다. 일부 실시예에서, 결제 처리 모듈은 (예를 들어, 캐쉬백 또는 멤버십 보상 트랜잭션을 되돌리기 위하여) 이전 거래를 취소하고 고객에게 환불해야만 하는 금액을 결정하기 위해 연락해야 하는 엔티티를 식별하기 위해, 혜택 데이터와 연관 주문 정보를 사용할 수 있다.
단계 605에서, 결제 처리 모듈은 개별 환불 요청을 포함하는 API 호출 세트를 적합한 결제 중개자에게 전송할 수 있다. 여기에서 결제 중개자는 고객에 의해 사용된 결제 방법을 위한 결제 프로세서뿐만 아니라 위의 단계 604에서 식별된 엔티티를 포함할 수 있다.
단계 606에서, 결제 처리 모듈은 결제 중개자 각각으로부터, 개별 환불 요청이 완료되었고 환불이 발행되었음(또는 추가 처리 후에 발행될 것임)을 확인하는, 외부 환불 확인을 수신할 수 있다.
단계 607에서, 결제 처리 모듈은 외부 환불 확인이 모든 결제 중개자로부터 수신되면 내부 환불 확인을 워크플로우 서비스 모듈(385)로 다시 전송할 수 있다. 일부 실시예에서, 내부 환불 확인은 환불이 발행되었고 단계 506 및 508에서 상술된 것처럼 고객 디바이스로 알림을 전송하는 것으로 진행할 수 있음을 워크플로우 서비스 모듈(385)에 나타낼 수 있다.
본 개시는 그 특정 실시예를 참조하여 도시되고 설명되었지만, 본 개시는 다른 환경에서, 변경없이, 실시될 수 있음을 이해할 것이다. 전술한 설명은 예시의 목적으로 제시되었다. 그것은 개시된 정확한 형태나 실시예에 대해 총망라된 것이 아니며 이것으로 한정되는 것은 아니다. 개시된 실시예의 설명 및 실시를 고려하는 것으로부터 변경 및 조정이 통상의 기술자에게 명백할 것이다. 추가적으로, 비록 개시된 실시예의 형태가 메모리에 저장되는 것으로서 설명되었지만, 통상의 기술자는 이들 형태가 2차 저장 디바이스, 예를 들면, 하드디스크나 CD ROM, 또는 다른 형태의 RAM이나 ROM, USB 매체, DVD, 블루레이, 또는 다른 광 드라이브 매체와 같이, 다른 형태의 컴퓨터 판독 가능한 매체에 저장될 수도 있는 것을 이해할 것이다.
상술한 설명 및 개시된 방법에 기초한 컴퓨터 프로그램은 숙련된 개발자의 기술 내에 있다. 여러 프로그램 혹은 프로그램 모듈은 통상의 기술자에게 알려진 어느 기술을 이용하여 생성되거나, 또는 기존의 소프트웨어와 연결하여 설계될 수 있다. 예를 들면, 프로그램 섹션 혹은 프로그램 모듈은 닷넷 프레임워크, 닷넷 컴팩트 프레임워크(및 비주얼 베이식, C 등과 같은, 관련 언어), 자바, C++, 오브젝티브 C, HTML, HTML/AJAX 조합, XML, 또는 자바 애플릿이 포함된 HTML 내에서 혹은 그것들에 의해서 설계될 수 있다.
게다가, 여기에서는 예시적인 실시예가 설명되었지만, 본 개시에 기초하여 통상의 기술자가 이해할 수 있는 바와 같이, 일부 또는 모든 실시예의 범위는 동등한 요소, 변경, 생략, 조합(예로써, 여러 실시예에 걸치는 형태의 조합), 조정 및/또는 수정을 가질 수 있다. 청구범위 내의 제한 사항은 그 청구범위 내에 적용된 언어에 기초하여 폭넓게 이해되도록 하는 것이며, 응용의 수행 동안 혹은 본 명세서 내에 설명된 예시로 한정되는 것은 아니다. 그 예시는 비배타적으로 해석되도록 하기 위한 것이다. 추가로, 개시된 방법의 스텝은 어떤 다른 방법으로 변경되거나, 스텝을 재배열 및/또는 스텝을 삽입하거나 삭제하는 것을 포함할 수 있다. 그러므로, 설명 및 예시는 오직 예시적으로 고려되는 것이며, 진정한 범위 및 기술 사상은 다음의 청구범위 및 그 동등한 전체 범위에 의해 나타내지는 것으로 의도된다.
Claims (20)
- 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 시스템으로서,
명령을 저장하도록 구성된 적어도 하나의 비일시적 컴퓨터-판독가능 매체; 및
동작들을 수행하기 위해 상기 명령을 실행시키도록 구성된 적어도 하나의 프로세서를 포함하고;
상기 동작들은
사용자 디바이스로부터 반품 아이템의 반품을 요청하는 반품 API(application programming interface) 호출을 수신하고;
네트워크 데이터베이스의 데이터 레코드에 대해 상기 반품 API 호출을 검증하고;
상기 반품 아이템이 복수의 개별 아이템을 포함한다고 결정하고;
상기 개별 아이템의 서브세트가 결함이 있는지 여부를 결정하기 위해 상기 반품 API 호출의 반품 코드를 분석하고;
상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 제1 반품 프로세스에 적합한지 여부를 결정하고;
상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 상기 제1 반품 프로세스에 부적합한 경우, 제2 반품 프로세스를 시작하기 위해 API 호출을 생성하고;
상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 상기 제1 반품 프로세스에 적합한 경우:
상기 개별 아이템의 상기 서브세트에 상응하는 상기 반품 아이템의 가격의 부분을 결정하고;
환불로서 상기 반품 아이템의 상기 가격의 부분을 발행하기 위한 환불 API 호출을 생성하고;
상기 환불을 기록하기 위해 상기 네트워크 데이터베이스의 상기 데이터 레코드를 업데이트하고; 그리고
상기 반품 API 호출의 승인에 관한 알림을 상기 사용자 디바이스로 전송하는 것을 포함하는, 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 반품 API 호출을 검증하는 것은 중앙 저장소에 저장된 시스템 규칙에 기초하여 수행되는 컴퓨터 구현 시스템. - 청구항 2에 있어서,
상기 반품 API 호출을 검증하는 것은 상기 시스템 규칙 중 적어도 하나에 대해 상기 반품 API 호출의 준수(compliance)를 검증하는 것을 포함하는 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 반품 아이템이 상기 복수의 상기 개별 아이템을 포함한다고 결정하는 것은 상기 네트워크 데이터베이스의 상기 데이터 레코드에 대해 상기 반품 아이템과 연관된 카테고리 식별자를 찾는 것을 포함하는 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 반품 아이템의 상기 가격의 부분을 결정하는 것은 상기 개별 아이템에 대한 상기 개별 아이템의 상기 서브세트의 수량에 비례하는 금액을 결정하는 것을 포함하는 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 반품 아이템의 상기 가격의 부분을 결정하는 것은 상기 개별 아이템에 대한 상기 개별 아이템의 상기 서브세트의 비율에 승수(multiplier)가 곱해진 것에 비례하는 금액을 결정하는 것을 포함하는 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 환불 API 호출을 생성하는 것은 상기 환불 API 호출을 결제 관리 시스템으로 전송하는 것을 포함하는 컴퓨터 구현 시스템. - 청구항 1에 있어서,
상기 동작들은
상기 반품 코드를 분석한 결과에 기초하여 상기 반품 아이템의 회수(retrieval)를 요청하는 회수 API 호출을 생성하는 것을 더 포함하는 컴퓨터 구현 시스템. - 청구항 8에 있어서,
상기 환불 API 호출을 생성하는 것은 추가로 상기 회수 API 호출이 처리되었다는 결정에 응답하는 것인 컴퓨터 구현 시스템. - 청구항 9에 있어서,
상기 동작들은
환불로서 상기 반품 아이템의 전체 가격을 발행하도록 상기 환불 API 호출을 수정하는 것을 더 포함하는 컴퓨터 구현 시스템. - 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 방법으로서,
적어도 하나의 프로세서에 의해, 사용자 디바이스로부터 반품 아이템의 반품을 요청하는 반품 API 호출을 수신하고;
상기 적어도 하나의 프로세서에 의해, 네트워크 데이터베이스의 데이터 레코드에 대해 상기 반품 API 호출을 검증하고;
상기 적어도 하나의 프로세서에 의해, 상기 반품 아이템이 복수의 개별 아이템을 포함한다고 결정하고;
상기 적어도 하나의 프로세서에 의해, 상기 개별 아이템의 서브세트가 결함이 있는지 여부를 결정하기 위해 상기 반품 API 호출의 반품 코드를 분석하고;
상기 적어도 하나의 프로세서에 의해, 상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 제1 반품 프로세스에 적합한지 여부를 결정하고;
상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 상기 제1 반품 프로세스에 부적합한 경우, 제2 반품 프로세스를 시작하기 위해 상기 적어도 하나의 프로세서에 의해, API 호출을 생성하고;
상기 개별 아이템의 상기 서브세트에 대한 상기 반품 API 호출이 상기 제1 반품 프로세스에 적합한 경우:
상기 적어도 하나의 프로세서에 의해, 상기 개별 아이템의 상기 서브세트에 상응하는 상기 반품 아이템의 가격의 부분을 결정하고;
상기 적어도 하나의 프로세서에 의해, 환불로서 상기 반품 아이템의 상기 가격의 부분을 발행하기 위한 환불 API 호출을 생성하고;
상기 적어도 하나의 프로세서에 의해, 상기 환불을 기록하기 위해 상기 네트워크 데이터베이스의 상기 데이터 레코드를 업데이트하고; 그리고
상기 적어도 하나의 프로세서에 의해, 상기 반품 API 호출의 승인에 관한 알림을 상기 사용자 디바이스로 전송하는 것을 포함하는, 컴퓨터 구현 방법. - 청구항 11에 있어서,
상기 반품 API 호출을 검증하는 것은 중앙 저장소에 저장된 시스템 규칙에 기초하여 수행되는 컴퓨터 구현 방법. - 청구항 12에 있어서,
상기 반품 API 호출을 검증하는 것은 상기 시스템 규칙 중 적어도 하나에 대해 상기 반품 API 호출의 준수를 검증하는 것을 포함하는 컴퓨터 구현 방법. - 청구항 11에 있어서,
상기 반품 아이템이 상기 복수의 상기 개별 아이템을 포함한다고 결정하는 것은 상기 네트워크 데이터베이스의 상기 데이터 레코드에 대해 상기 반품 아이템과 연관된 카테고리 식별자를 찾는 것을 포함하는 컴퓨터 구현 방법. - 청구항 11에 있어서,
상기 반품 아이템의 상기 가격의 부분을 결정하는 것은 상기 개별 아이템에 대한 상기 개별 아이템의 상기 서브세트의 수량에 비례하는 금액을 결정하는 것을 포함하는 컴퓨터 구현 방법. - 청구항 11에 있어서,
상기 반품 아이템의 상기 가격의 부분을 결정하는 것은 상기 개별 아이템에 대한 상기 개별 아이템의 상기 서브세트의 비율에 승수가 곱해진 것에 비례하는 금액을 결정하는 것을 포함하는 컴퓨터 구현 방법. - 청구항 11에 있어서,
상기 적어도 하나의 프로세서에 의해, 상기 반품 코드를 분석한 결과에 기초하여 상기 반품 아이템의 회수를 요청하는 회수 API 호출을 생성하는 것을 더 포함하는 컴퓨터 구현 방법. - 청구항 17에 있어서,
상기 환불 API 호출을 생성하는 것은 추가로 상기 회수 API 호출이 처리되었다는 결정에 응답하는 것인 컴퓨터 구현 방법. - 청구항 18에 있어서,
상기 적어도 하나의 프로세서에 의해, 환불로서 상기 반품 아이템의 전체 가격을 발행하도록 상기 환불 API 호출을 수정하는 것을 더 포함하는 컴퓨터 구현 방법. - 네트워크 부하를 최소화하기 위해 아이템을 수령하지 않고 부분 환불을 처리하기 위한 컴퓨터 구현 시스템으로서,
명령을 저장하도록 구성된 적어도 하나의 비일시적 컴퓨터-판독가능 매체; 및
동작들을 수행하기 위해 상기 명령을 실행시키도록 구성된 적어도 하나의 프로세서를 포함하고;
상기 동작들은
사용자 디바이스로부터 아이템의 일부에 대한 반품을 요청하는 반품 API 호출을 수신하고;
상기 아이템의 상기 일부와 상기 아이템 전체 간의 비율을 결정하기 위해 상기 반품 API 호출을 파싱하고;
상기 아이템의 상기 일부와 연관된 카테고리 식별자를 상기 반품 API 호출에 포함된 이유 코드와 비교하고;
만약 상기 카테고리 식별자가 상기 이유 코드에 대해 수용 가능하면,
환불 API 호출을 결제 관리 시스템으로 전송하고,
상기 비율에 기초하여 환불을 기록하기 위해 네트워크 데이터베이스의 데이터 레코드를 업데이트하고, 그리고
상기 반품 API 호출의 승인에 관한 알림을 상기 사용자 디바이스로 전송하고; 그리고
만약 상기 카테고리 식별자가 상기 이유 코드에 대해 수용 가능하지 않으면,
상기 아이템의 상기 일부의 회수를 요청하는 회수 API 호출을 생성하고,
상기 아이템의 상기 일부가 회수되면 상기 아이템의 상기 일부의 아이템 식별자를 캡처하고,
상기 아이템의 상기 일부의 상기 회수를 기록하기 위해 상기 네트워크 데이터베이스의 상기 데이터 레코드를 업데이트하고,
상기 환불 API 호출을 상기 결제 관리 시스템으로 전송하고,
상기 비율에 기초하여 환불을 기록하기 위해 상기 네트워크 데이터베이스의 상기 데이터 레코드를 업데이트하고, 그리고
상기 반품 API 호출의 승인에 관한 알림을 상기 사용자 디바이스로 전송하는 것을 포함하는, 컴퓨터 구현 시스템.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1020230048698A KR20230054804A (ko) | 2021-01-14 | 2023-04-13 | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US17/148,610 US11216821B1 (en) | 2021-01-14 | 2021-01-14 | Systems and methods for breaking up select requests to streamline processes and improve scalability |
| US17/148,610 | 2021-01-14 |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020230048698A Division KR20230054804A (ko) | 2021-01-14 | 2023-04-13 | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR20220103020A KR20220103020A (ko) | 2022-07-21 |
| KR102523033B1 true KR102523033B1 (ko) | 2023-04-19 |
Family
ID=79169529
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020210148297A KR102523033B1 (ko) | 2021-01-14 | 2021-11-01 | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 |
| KR1020230048698A KR20230054804A (ko) | 2021-01-14 | 2023-04-13 | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020230048698A KR20230054804A (ko) | 2021-01-14 | 2023-04-13 | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US11216821B1 (ko) |
| KR (2) | KR102523033B1 (ko) |
| TW (1) | TW202234326A (ko) |
| WO (1) | WO2022153089A1 (ko) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20220292519A1 (en) * | 2021-03-15 | 2022-09-15 | Ncr Corporation | Item return data integration processing |
| US20230297943A1 (en) * | 2022-03-18 | 2023-09-21 | Affirm, Inc. | Method and Apparatus for Facilitating Provision of Instant Credit to Customers VIA Rapid and Machine Learning Supported Underwriting Decisions |
| KR20230151305A (ko) * | 2022-04-25 | 2023-11-01 | 쿠팡 주식회사 | 아이템 거래와 관련된 정보를 제공하는 장치 및 그 방법 |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007328779A (ja) * | 2000-03-28 | 2007-12-20 | Iship Inc | オンライン、複数小包、複数運送業者、複数サービスの小包返品荷送マネジメントのための装置、システム及び方法 |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3710172B2 (ja) * | 1995-09-01 | 2005-10-26 | 富士通株式会社 | ソフトウェア代金返金用ユーザ端末およびセンタ |
| US20030225625A1 (en) * | 2002-05-31 | 2003-12-04 | Michael Chew | Returns management systems and methods therefor |
| JP2009517775A (ja) | 2005-12-02 | 2009-04-30 | ウェルカム リアル−タイム ピーティーイー エルティディー． | 返品承認方法及びそのシステム |
| US8126778B2 (en) * | 2007-03-19 | 2012-02-28 | Ebay Inc. | Network reputation and payment service |
| US20100145754A1 (en) * | 2008-12-09 | 2010-06-10 | United Parcel Service Of America, Inc. | Systems, methods, apparatuses and computer program products for generating customized return notifications |
| US8306877B2 (en) * | 2010-01-29 | 2012-11-06 | Xerox Corporation | System and method for managing consumable return refund processing |
| US20120215615A1 (en) | 2011-08-29 | 2012-08-23 | Triggerback, LLC | Conditional Partial Refund Based on Units Sold |
| US9292824B1 (en) * | 2011-10-25 | 2016-03-22 | Amazon Technologies, Inc. | Medium for facilitating initiation of customer returns |
| GB201304277D0 (en) * | 2013-03-11 | 2013-04-24 | Clear Returns Ltd | Data processing systems for use in retail business |
| EP3011513A4 (en) | 2013-04-29 | 2017-04-19 | Boku, Inc. | Billing gateway |
| KR20150067024A (ko) | 2013-12-09 | 2015-06-17 | 아마데우스 에스.에이.에스. | 전자 제반 문서(emd)의 자동화된 환불 |
| US20160350756A1 (en) * | 2015-05-29 | 2016-12-01 | Telecommunication Systems, Inc. | Consumer return of defective products via mobile device photograph submission |
| US10387146B2 (en) * | 2015-11-30 | 2019-08-20 | Visa International Service Association | System and method for common request processing |
| US10791109B2 (en) | 2016-02-10 | 2020-09-29 | Red Hat, Inc. | Certificate based expiration of file system objects |
| US11257095B2 (en) * | 2016-10-20 | 2022-02-22 | Toshiba Global Commerce Solutions Holdings Corporation | Visual sensor-based management of a return transaction |
| SG10201800546XA (en) * | 2018-01-22 | 2019-08-27 | Mastercard International Inc | Electronic transaction data processing systems and methods |
| KR20200129412A (ko) * | 2019-05-08 | 2020-11-18 | 아나나스 유한책임회사 | 판매자를 위한 온라인 쇼핑몰 통합관리 시스템 및 방법 |
| US11055656B2 (en) * | 2019-06-06 | 2021-07-06 | Motogo, Llc | Systems and methods of package container return |
| US11004087B1 (en) * | 2020-06-08 | 2021-05-11 | Coupang Corp. | Systems and methods for processing exception event request to identify defective product |
-
2021
- 2021-01-14 US US17/148,610 patent/US11216821B1/en active Active
- 2021-02-03 WO PCT/IB2021/050874 patent/WO2022153089A1/en active Application Filing
- 2021-11-01 KR KR1020210148297A patent/KR102523033B1/ko active IP Right Grant
- 2021-11-10 US US17/523,052 patent/US12039541B2/en active Active
- 2021-12-27 TW TW110148934A patent/TW202234326A/zh unknown
-
2023
- 2023-04-13 KR KR1020230048698A patent/KR20230054804A/ko not_active Application Discontinuation
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007328779A (ja) * | 2000-03-28 | 2007-12-20 | Iship Inc | オンライン、複数小包、複数運送業者、複数サービスの小包返品荷送マネジメントのための装置、システム及び方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| US20220222667A1 (en) | 2022-07-14 |
| US12039541B2 (en) | 2024-07-16 |
| US11216821B1 (en) | 2022-01-04 |
| KR20230054804A (ko) | 2023-04-25 |
| KR20220103020A (ko) | 2022-07-21 |
| WO2022153089A1 (en) | 2022-07-21 |
| TW202234326A (zh) | 2022-09-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102523033B1 (ko) | 프로세스 능률화와 확장성 향상을 위해 선택 요청을 쪼개기 위한 시스템 및 방법 | |
| KR102467500B1 (ko) | 비동기적으로 큐에 더해진 요청의 오류를 검출하는 시스템 및 방법 | |
| TWI839610B (zh) | 偵測與避免退貨詐欺之系統以及方法 | |
| TWI777543B (zh) | 用於工作流程編輯的電腦實施系統以及方法 | |
| KR102530936B1 (ko) | 자동화된 정보 수집 및 처리를 위한 시스템 및 방법 | |
| US11665257B2 (en) | Systems and methods for managing perpetual data requests to conserve resources | |
| KR102501140B1 (ko) | 확장성을 개선하기 위해 선택 프로세스를 간소화하는 시스템 및 방법 | |
| TWI851514B (zh) | 用於在不接收物件的情況下處理退貨以最小化網路負載的電腦實行系統以及方法 | |
| KR102402074B1 (ko) | 이벤트 저장 관리를 위한 시스템 및 방법 | |
| TWI856782B (zh) | 用於包裹遞送的電腦實行系統以及用於儲存與一系列事件相關的資料的電腦實行資料庫方法 | |
| TW202433364A (zh) | 偵測與避免退貨詐欺之系統以及方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| E902 | Notification of reason for refusal | ||
| E701 | Decision to grant or registration of patent right |