Systems and methods for electronic platform for inventory sharing

A computer-implemented method for managing data associated with electronic inventory management of wearable articles includes receiving, wearable article data describing wearable articles made available for physical shipment to users via electronic interactions, wherein one or more electronic interfaces are accessible over one or more networks. The method includes assigning a category to one or more wearable articles described in the wearable article data, the category being selected from a plurality of categories including a first category for selection by a first plurality of users and a second category for selection by a second plurality of users. The method also includes monitoring availability data, the availability data indicating an availability of one or more wearable articles for selection by one or more users interacting with a first electronic storefront, a second electronic storefront, or both, and initiating one or more services to facilitate physical shipment of a first wearable article.

TECHNICAL FIELD

Aspects of the present disclosure relate to an electronic platform for distribution and inventory management of wearable items and, more particularly, to dynamically managing electronic data associated with dynamic allocations of articles, such as wearable items.

BACKGROUND

Services for providing articles, including electronically-presented services, typically adhere to an established, conventional structure. In these services, entities such as retailers design and manufacture, or otherwise obtain, a series of products that are offered for purchase. In the example of wearable articles including garments, a group of products can be offered for a period of time, such as a season, after which the articles are offered at a reduced price. Entities offering articles via one or more electronic destinations, such as a website, employ conventional allocation strategies, allotting each individual article to a particular purpose. For example, articles are allocated for purchase so that when stock of a particular article is exhausted, the website can be updated appropriately. When a large number of articles are present (e.g., unsold) after a period of time, the website or other electronic destination can be updated with a reduced price to encourage selection of these articles. Each article, and often the electronic destination itself, is typically dedicated to a specific purpose, such as one-time purchases, auction-style purchases, rentals, etc.

While article subscriptions have recently experienced increased visibility and market importance, there are circumstances where a one-time rental system is desirable. However, implementing new systems to enable a new service, presents numerous technical challenges that involve significant design efforts and infrastructure to support new inventory systems, user experience design, cost structure, and others. Thus, conventional systems lack the capabilities to flexibly and dynamically link a plurality of service types (e.g., one-time purchases, one-time rentals, and/or subscription services), identify different users across these services, and facilitate interactions between different types of entities involved in management of these services. Additionally, while operating one of these services involves the generation and tracking of vast amounts of information that may be useful for monitoring storefront performance, service-type performance, article performance, etc., this information is generated and stored by individual entities and/or for an individual service. Thus, the ability to dynamically monitor, update, and analyze this information is limited.

SUMMARY OF THE DISCLOSURE

According to certain aspects of the disclosure, systems and methods are disclosed for dynamically managing electronic data associated with a plurality of services, such as services associated with wearable items or other articles offered by a plurality of entities, including entities having different roles (e.g., hosting entities, fulfiller entities, and others).

In one aspect, a computer-implemented method for managing data associated with electronic inventory management of wearable articles may include receiving, by one or more processors, wearable article data from one or more electronic interfaces, the wearable article data describing wearable articles made available for physical shipment to users via electronic interactions, wherein the one or more electronic interfaces are accessible over one or more networks. The method may include assigning, by the one or more processors, a category to one or more wearable articles described in the wearable article data, the category being selected from a plurality of categories including a first category for selection by a first plurality of users and a second category for selection by a second plurality of users, the category being stored as categorization assignment data. The method may also include monitoring, by the one or more processors, availability data included in the wearable article data for one or more wearable articles, the availability data indicating an availability of one or more wearable articles for selection by one or more users interacting with a first electronic storefront, an availability of the one or more articles for selection by one or more users interacting with a second electronic storefront, or both, and in response to receiving one or more user selections via the first electronic storefront, the second electronic storefront, or both, initiating one or more services to facilitate physical shipment of a first wearable article.

In another aspect, a computer system for managing data associated with electronic inventory management of wearable articles may include a memory having processor-readable instructions stored therein and one or more processors configured to access the memory and execute the processor-readable instructions. The processor-readable instructions, when executed by the one or more processors may configure the one or more processors to perform a plurality of functions. The functions may include functions for receiving, by the one or more processors, wearable article data from one or more electronic interfaces, the wearable article data describing wearable articles made available for physical shipment to users via electronic interactions, wherein the one or more electronic interfaces are accessible over one or more networks, and assigning, by the one or more processors, a category to one or more wearable articles described in the wearable article data, the category being selected from a plurality of categories including a first category for selection by a first plurality of users and a second category for selection by a second plurality of users. The functions may further include functions for monitoring, by the one or more processors, availability data included in the wearable article data for one or more wearable articles, the availability data indicating an availability of one or more wearable articles for selection by one or more users interacting with a first electronic storefront, an availability of the one or more articles for selection by one or more users interacting with a second electronic storefront, or both, and in response to receiving one or more user selections via the first electronic storefront, the second electronic storefront, or both, initiating one or more services to facilitate physical shipment of a first wearable article.

In yet another aspect, a non-transitory computer-readable medium may contain instructions for performing functions for managing data associated with electronic inventory management of wearable articles. The functions may include receiving wearable article data from one or more electronic interfaces, the wearable article data describing wearable articles made available for physical shipment to users via electronic interactions, wherein the one or more electronic interfaces are accessible over one or more networks, and assigning a category to one or more wearable articles described in the wearable article data, the category being selected from a plurality of categories including a first category for selection by a first plurality of users and a second category for selection by a second plurality of users, the category being stored as categorization assignment data. The functions may further include monitoring availability data included in the wearable article data for one or more wearable articles, the availability data indicating an availability of one or more wearable articles for selection by one or more users interacting with a first electronic storefront, an availability of the one or more articles for selection by one or more users interacting with a second electronic storefront, or both, and in response to receiving one or more user selections via the first electronic storefront, the second electronic storefront, or both, initiating one or more services to facilitate physical shipment of a first wearable article.

DETAILED DESCRIPTION OF EMBODIMENTS

The following embodiments describe systems and methods for dynamically managing inventory data associated with articles, such as apparel or other wearable items associated with purchase services, rental services, and/or subscription services. In particular, aspects of the present disclosure may relate to systems and methods for managing inventory assignment for a plurality of entities in which one or more articles are made available for selection by a user interacting with an interface provided on behalf of a hosting entity.

While the exemplary system architecture as described in the present disclosure relates to electronic transactions for subscribing to, purchasing, or renting wearable items (e.g., by offering clothing-as-a-service (CaaS) or other articles-as-a-service, a Try-Then-Buy (TTB) service such as a service for renting an article for a set or flexible period of time with the option to purchase the article at a discounted TTB price, transaction rental services, etc.), implementations disclosed herein may effectively serve various other online transactions in the context of any other subscription, purchase, rental, or retail services without departing from the scope of the disclosure, such as, for example, subscribing to or making purchases in a software service, cleaning service, delivery service, maintenance service, rental product, rental vehicles, etc. In addition, while some descriptions and examples disclosed in the present disclosure refer to certain exemplary interactions (e.g., transactions) as transactions pertaining to “apparel,” “garments,” “wearable articles,” or “wearable items,” all of those transactions may effectively serve any article or consumer good without departing from the scope of the disclosure.

As used in the present disclosure, the term “CaaS” (i.e., clothing-as-a-service) may collectively refer to computer-implemented services and functions associated with subscription, purchase, and/or rental services for users (e.g., periodic subscription for receiving wearable items, apparel rental or purchase order, distribution, return processing, TTB services, transaction rental services, account management, marketing, customer service, warehouse operations, etc.). As used in the present disclosure, the terms “wearable item” and/or “wearable article” may refer to any article of clothing, apparel, jewelry, hat, accessories, or other product which may be worn by a person, an animal, or a thing, or be used as an ornament for a person, an animal, or a thing. As used herein, the term “closeting” or “to closet” may refer to a computer-implemented operation of placing one or more garments into a virtual closet (e.g., a cart, a repository, or any type of space which may be virtually associated with a particular set of one or more garments for a future transaction). Additionally, “matching” may refer to a computer-implemented operation of determining a set of one or more garments for allocating to a user and/or determining wearability metrics for given garments, and “allocating” or “allocation” may refer to a computer-implemented operation of determining garments that should be assigned and shipped to one or more particular users. “Allocating” or “allocation” may also refer to computer-implemented operations for determining garments that should be assigned to one or more pools or groups of articles made available for selection by a user via a transaction rental service. An “inventory” may refer to a plurality of articles that are associated with one or more entities. A “catalog” may refer to a plurality of articles associated with one or more entities, such as one or more articles presented via an electronic storefront and/or via an interface of an inventory exchange. The term “physical inventory” includes articles physically provided to a logistics center, warehouse, or one or more other location(s).

In accordance with the present disclosure, user interfaces, periodically executed computer-implemented services, ad hoc services, and automations being integrated together in a connected platform may be achieved by a uniquely configured system architecture, configuring one or more processors to perform storefront and back office tasks, and various user interfaces providing specialized or customized access to entities associated with one or more roles. For example, the system may collect vast amounts of information and data attributes from historical transactions with users, historical transactions or other interactions, form data sets indicative of different entities' relationships with certain articles and/or other entities, etc. These interfaces, services, and automations may be useful for operating and managing an article transaction rental service and synchronizing information between the storefronts associated with the various entities with an inventory availability and valuation service.

Article merchants of all types, and in particular, apparel retailers, invest significant resources developing effective systems to facilitate article interactions, including article purchases. However, many systems, and indeed numerous industries including the apparel, jewelry, and other consumer products industries, to name a few, remain ownership-based, such that users purchase individual articles by navigating a website, in a manner that is analogous to interacting with a physical retail location. Due to this ownership-based model, a user's purchasing power limits access to articles that are offered for sale by article merchants. Thus, end-users are unable to access articles that will be used a limited number of times and/or that have a relatively high cost. Systems and methods described herein may, in at least some embodiments, allow end-users to access articles at a fraction of the purchase cost, retain the article as long as desired, and purchase the article when desired. Additionally, as users have become more value-conscious, a rental option is desirable in many circumstances. In some embodiments, entities may, by use of the disclosed methods and systems, create new monetization channels for their article(s). The channels may result in either or both an increase in or more consistent and predictable demand. Additionally, in at least some embodiments, entities may benefit from increased user retention, which may facilitate increased brand loyalty, which would otherwise be reduced when user purchasing power is reduced.

The subject matter of the present description will now be described more fully hereinafter with reference to the accompanying drawings, which form a part thereof, and which show, by way of illustration, specific exemplary embodiments. An embodiment or implementation described herein as “exemplary” is not to be construed as preferred or advantageous, for example, over other embodiments or implementations; rather, it is intended to reflect or indicate that the embodiment(s) is/are “example” embodiment(s). Subject matter can be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any exemplary embodiments set forth herein; exemplary embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope for claimed or covered subject matter is intended. Among other things, subject matter may be embodied as methods, devices, components, or systems. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (other than software per se). The following detailed description is, therefore, not intended to be taken in a limiting sense.

Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond or in addition to an explicitly stated meaning. Likewise, the phrase “in one embodiment” as used herein does not necessarily refer to the same embodiment or aspect of the disclosure and the phrase “in another embodiment” as used herein does not necessarily refer to a different embodiment or aspect of the disclosure. It is intended, for example, that claimed subject matter include combinations of exemplary embodiments in whole or in part.

I. Exemplary System Environment

FIG. 1shows an example environment100, according to one or more embodiments of the present disclosure. As shown, the example environment100may include one or more networks101that interconnect a server system102, user devices112, employee devices116, entity devices118,132,142, and external systems122. The one or more networks101may be, for example, one or more of a cellular network, a public land mobile network, a local area network, a wide area network, a metropolitan area network, a telephone network, a private network, an ad hoc network, an intranet, the Internet, a fiber optic based network, a cloud computing network, etc. User devices112may be accessed by users108, employee devices116may be accessed by authorized employees114, and entity devices118,132,142may be accessed by different entities120,136,146, as described below. In some implementations, employee devices116may be used to perform or supplement the functions of entity devices118,132,142and/or the functions of user devices112. A server system102may comprise one or more servers104and one or more databases106, which may be configured to store and/or process a plurality of data, microservices, and service components, and/or associated functions thereof, as described in more detail below with respect toFIGS. 2 and 3.

Users108may access server system102through the one or more networks101via user devices112. Each device among user devices112may be any type of computing device (e.g., personal computing device, mobile computing device, etc.) which allows users108to display a web browser or a web-based application for accessing the server system102through the network101. User devices112may, for example, be configured to display a web browser, a web-based application, or any other user interface (e.g., one or more mobile applications) for allowing users108to exchange information with other device(s) or system(s) in environment100over the one or more networks101. For example, user devices112may load an application with a graphical user interface (GUI), and the application may display, on the GUI, one or more article recommendations for closeting and/or for transaction rental by the user. Users108accessing user devices112may be, for example, users and/or potential users of articles made available for subscription-based, transaction rental-based, and/or purchase-based distribution via electronic transactions and physical shipment. Additionally, or alternatively, users108may access user devices112to, for example, view articles that were ordered as part of a transaction rental service, manage one or more user accounts, view catalogs, configure one or more user profiles, engage in customer service communications, make purchase orders, track shipments, generate shipments, monitor order fulfillment processes, initiate or process returns, order apparel for purchase, provide feedback, refer other users, navigate through various features such as size advisor, perform personalized discovery, and/or make recommendations.

Employee devices116may be configured to be accessed by one or more employees114, including, for example, customer service employees, marketer employees, warehouse employees, analytics employees, or any other employees who are authorized and/or authenticated to perform tasks, operations, and/or transactions associated with server system102, and/or external systems122. In at least one embodiment, employee devices116are owned and operated by the same entity or at least an affiliate of the entity operating the e-commerce (e.g., CaaS) business hosted on server systems102. Each employee device116may be any type of computing device (e.g., personal computing device, mobile computing devices, etc.). Employee devices116may allow employees114to display a web browser or an application for accessing the server system102and/or the external systems122, through the one or more networks101. For example, an employee device116may load an application with graphical user interface (GUI), and the application may display on the GUI one or more warehouse operations associated with providing CaaS to users108. In some implementations, employee devices116may communicate directly with server system102via communications link117, bypassing public networks101. Additionally, or alternatively, employee devices116may communicate with server system102via network101(e.g., access by web browsers or web-based applications).

Entity devices118,132,142may be configured to be accessed by one or more entities, such as one or more fulfiller entities120, one or more hosting entities136associated with a hosted electronic storefront for article transactions (e.g., purchases), and/or one or more additional entities146, which may include fulfiller entities, hosting entities, and/or entities that act as both hosting and fulfillment entities, as described below. A fulfiller entity120may include, in at least some implementations, a “tenant” entity that interacts with a CaaS operator to engage one or more subscribing users and offer articles as part of a service (e.g., a subscription service) to participants in the service (e.g., users108). However, fulfiller entities120are not necessarily tenants of associated with a CaaS operator.

Each device among the devices118,132,142may be any type of computing device (e.g., personal computing device, mobile computing devices, etc.). As used herein, each entity, including one or more entities120,136,146, may refer to an entity that receives, supplies, shares, and/or facilitates article interactions, including one-time rentals, purchases, and/or subscription operations, for one or more collections of apparel or other articles. For example, fulfiller entities120and/or additional entities146may include one or more entities that offer a subscription service or other CaaS. The collections of apparel or other articles may be included as part of one or more CaaS inventories or one or more separate inventories to facilitate an article integration service that allows entities120,136,146to implement a transaction rental system. For example, each entity120,136,146may be a retailer, a designer, a manufacturer, a merchandiser, a brand owner, or other entity that supplies or otherwise makes available one or more collections (e.g., catalogs) of wearable items to one or more CaaS inventories managed and/or accessed by the server system102.

Entities120,136,146may be configured to interact with each other, via an article integration service, according to one or more roles, as described below. For example, fulfillment or fulfiller entities120may be entities that provide a plurality of articles to one or more physical inventories of a CaaS, and ultimately, for use by other entities, such as one or more hosting entities136. In some embodiments, fulfiller entities120may provide one or more articles directly to one or more hosting entities136and/or one or more users108associated with one or more hosting entities136.

Hosting entities136may, via one or more electronic storefronts, make articles available to one or more users108. These electronic storefronts may be configured as storefronts for purchasing articles. It should be appreciated that an entity may not always be a “fulfiller entity” vs. a “hosting entity.” Rather, an entity may be a fulfiller vs. hosting entity depending on which side of a transaction the entity is on, for any given transaction. It is contemplated that, at any given moment, an entity may be a “hosting entity” with respect to a first transaction involving a first entity, while simultaneously acting as a “fulfiller entity” with respect to a second transaction involving a second entity. Additional entities146may include entities that act as both fulfiller and hosting entities120,136, and/or entities that facilitate article integration in electronic storefront catalogs of a plurality of entities (e.g., one or more fulfiller entities120and one or more hosting entities136).

As described in more detail below with respect toFIG. 3, entities120,136,146may use one or more electronic entity interfaces (e.g., a catalog content management system associated with each entity) to provide server system102with wearable item data that describe apparel or wearable items made available for allocation across one or more inventories via server system102. For example, one or more catalogs for each of the one or more entities120,136,146may be generated and/or updated at the server system102dynamically and/or periodically. Server system102may further facilitate services for making one or more articles available for transaction rental(s) via a storefront for one or more hosting entities136. For example, one or more articles may be designated or selected for inclusion in a pooled inventory, where such articles may be offered for a transaction rental service via one or more electronic storefronts associated with hosting entities136, as described below. At least one of these articles may be offered in another service (e.g., a subscription service and/or an expedited system component of the subscription service) in addition to the transaction rental service, and thus may be considered to be “pooled” between the two services. While the multiple services associated with one or more pooled articles may be offered by different entities (e.g., a fulfiller entity120that offers one or more articles for selection as part of a subscription service and a hosting entity136that offers transaction rentals via articles in an inventory for the subscription service of the fulfiller entity120), in some implementations the multiple services may be associated with a single entity (e.g., a single fulfiller or hosting entity120,136).

Devices118,132,142may serve as access terminals for the entities120,136,146for communicating with electronic interfaces and/or other subsystems hosted at server system102. Entity devices118,132,142may, for example, be configured to display a web browser, an application, or any other user interface for allowing entities120,136,146to load electronic interfaces and/or exchange data with other device(s) or system(s) in the environment100over the one or more networks101.

External systems122may be, for example, one or more third party and/or auxiliary systems that integrate and/or communicate with the server system102in performing various CaaS tasks. Specific examples of the external systems122are described in detail below with respect toFIGS. 2 and 3. External systems122may be in communication with other device(s) or system(s) in the environment100over the one or more networks101. For example, external systems122may communicate with the server system102via API (application programming interface) access over the one or more networks101, and also communicate with the employee devices116via web browser access over the one or more networks101.

As indicated above,FIG. 1is provided merely as an example. Other examples that differ from the example environment100ofFIG. 1are contemplated within the scope of the present embodiments. In addition, the number and arrangement of devices and networks shown in environment100are provided as an example. In practice, there may be additional devices, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in environment100. Furthermore, two or more devices shown inFIG. 1may be implemented within a single device, or a single device shown inFIG. 1may be implemented as multiple, distributed devices. Additionally, or alternatively, one or more devices may perform one or more functions of other devices in the example environment100. For example, employee devices116may be configured to perform one or more functions of devices118,132,142, in addition to their own functions.

FIG. 2is a schematic diagram of an exemplary architecture200for an electronic platform for offering clothing-as-a-service and/or articles-as-a-service utilizing article integration service(s), according to one or more embodiments. The components of architecture200may be accessed by authorized terminals, such as fulfiller/hosting entity devices202and user devices204, over the one or more networks101or via any one or more other types of network (e.g., a cellular network, a public land mobile network, a local area network, a wide area network, a metropolitan area network, a telephone network, a private network, an ad hoc network, an intranet, the internet, a fiber optic based network, a cloud computing network, etc.). As used herein, user devices204may correspond to any one or more user devices112of users108depicted inFIG. 1. One or more of the employee devices116depicted inFIG. 1may also access architecture200(e.g., via one or more internal applications). Fulfiller/hosting devices202may correspond to devices118of fulfiller entities120, devices132of hosting entities136, and/or devices142of additional entities146. Devices202may, in at least some circumstances, also correspond to one or more employee devices116.

As shown inFIG. 2, in general, architecture200may comprise an internal system206, external user facing apps208, a web application hosting server210, external systems212, and applications for inventory integration216which may be part of internal system206and/or formed by one or more external entity-facing applications. If desired, architecture200may include one or more entity data and analytics systems (not shown) to assess performance of, for example, individually-branded storefronts of entities120,136,146. Internal system206may comprise applications for inventory integration216, API endpoints218, APP endpoints220, login endpoints222, inventory services224, and inventory allocation data stores or data storage systems226.

II.A. Internal System

In operation, devices202may access internal system206, which may be stored at networked, distributed, and/or local systems (e.g., one or more virtual private clouds and/or one or more physical private networks). As used herein, a virtual private cloud may refer to a configurable pool of shared computing resources within a cloud environment, with groups of shared computing resources being allocated for a particular job(s), user(s) and/or a purpose(s). The outer boundary of the internal system206depicted in dashed lines, encompassing subcomponents216-230(with applications216being depicted in lighter dashed lines to indicate that components may be included in internal and/or external systems), may represent a virtual private cloud allocated for hosting the entirety of the internal system206. Additionally, the inner boundaries within internal system206, also depicted in dashed lines, may indicate multiple virtual private clouds (e.g., subsets of the larger virtual private cloud encompassing the internal system206), each allocated for one or more particular tasks, users, or purposes (e.g., inventory integration services224, inventory management jobs228, and data warehouse systems230).

Devices202may communicate with internal system206through one or more applications for inventory management216comprising one or more web-based portals or user interfaces for operations, including operations for accessing systems for designating one or more articles for availability via one or more storefronts associated with one or more hosting entities136(e.g., one or more articles made available for selection on a storefront that offers the same or similar articles for purchase and/or for rental via a subscription). Each portal may generate or present a graphical user interface on a display of one or more devices202. Applications for inventory integration216may include, for example, an inventory content management system and/or an inventory assignment portal. Entities120,136,146may use devices202to access internal system206to perform inventory management, inventory pooling (e.g., identifying one or more articles for availability for a transaction rental service via the storefront of another entity and/or another service such as a subscription service), article valuation, and/or other tasks.

In addition to applications for inventory management216, internal system206may include internal applications, such as one or more web-based user interfaces. These interfaces may include one or more mobile applications compatible with predetermined mobile device operating systems, a software application developed for desktop operating systems, and/or a web site configured for browser access to web pages via one or more networks (e.g., the Internet or an intranet). Employees114may use devices employee devices (e.g., user devices204) to access internal system206to perform additional tasks, such as CaaS functions related to warehouse operations and/or administrative tasks.

Internal system206may also include Application Programming Interface (“API”) endpoints218, APP (application) endpoints220, and login endpoints222. In some implementations, these endpoints may be hosted in a virtual private cloud or a physical private network. API endpoints218may be locations from which the APIs can access resources of the internal system206that the APIs need to carry out their functions. For example, the API endpoints218may specify where resources can be accessed by the APIs, while communicating with the APIs requesting information from the internal system206. APP endpoints220may be the locations from which applications (e.g., applications for inventory integration216, one or more internal applications) may access resources of the internal system206they need to carry out their functions, and the login endpoints222may be the touchpoints of any communication pertaining to logins (e.g., authentication and access control) associated with internal system206. Login endpoints222may receive and process login communications for applications for inventory integration216and/or external user facing applications208. At least some endpoints among the API endpoints218, APP endpoints220, and login endpoints222, may be entity-branded endpoints, designated to serve particular entities120,136,146.

In some aspects, different interfaces or functionalities may be associated with a role of each entity120,136,146(e.g., fulfiller entities120, hosting entities136, or others, such as an additional entities146), the role being determined based on login information received via one or more of the API endpoints218, APP endpoints220, and login endpoints222. Additionally or alternatively, separate API endpoints218, APP endpoints220, and/or login endpoints222may be provided for one or more particular roles.

Internal system206may include inventory integration services224that facilitate transaction rental systems or other pooled inventory functions, as well as inventory integration data storage systems226for storing information useful for operating, updating, and analyzing one or more aspects of the article integration service. Inventory integration services224may include services, such as microservices, for fulfillment of various CaaS operations hosted in one or more virtual private clouds or one or more physical private networks, including microservices that facilitate inventory integration for integrating articles in one or more electronic storefronts for transaction rental services. Inventory services224, which may include inventory availability and valuation services, may facilitate changes in articles offered for transaction rental services, changes in inventories based on articles selected for a storefront associated with one or more hosting entities136, and/or changes to valuation assigned to articles allocated to an inventory, such as an inventory of articles available for transaction rental services. In particular, one or more of these microservices may be configured to support external storefront integration, inventory reservations, value assessment and assignment, article status monitoring, and user targeting, as described in more detail below with respect to microservices356(FIG. 3). Additional microservices of internal system206may include, for example, account data, data services, customer service functions, marketing functions, warehouse functions, and/or other supporting functions.

Inventory integration data stores or storage systems226may be one or more databases that store both raw and processed data resulting from operations of inventory integration services224, endpoints218-222, external systems212, and/or data and analytics systems214. Inventory integration data storage systems226may store, for example, inventory data indicative of articles that were or are currently offered for transaction rental integration (e.g., articles selected by an entity for presentation via storefront(s) of one or more other entities), currently and previously rented articles (e.g., articles rented via transaction rental services), current and historical article valuations, performance of one or more pooled articles (e.g., a frequency or number of times one or more pooled articles is selected by a user via transaction rental services), among others. The data stored in data storage systems226may include transactional data, batch jobs data, searchable data including various analytics and attributes, event messages, and local logs of various raw data.

Internal system206may additionally include inventory management jobs228. Inventory management jobs228may be hosted in, for example, one or more virtual private clouds. Inventory management jobs228may include, for example, system components that run and update data associated with internal system206that are useful for pooled inventory and article sharing. In particular, system components of inventory management jobs228may be configured to receive and dynamically update data associated with articles that are offered for inventory sharing, currently shared articles, and/or articles that were previously shared and presented in storefront catalogs associated with (e.g., branded) one or more entities120,136,146. These system components may include, for example, components for identifying and storing historical data for each entity and each individual article or group of articles associated with one or more identifiers, snapshot data indicative of a current or recent (e.g., within 24 hours, within one week, etc.) status information of a plurality of articles, including articles included in one or more pooled inventories, articles that are currently available from a plurality of entities120,136,146for selection (e.g., closeting, selection for transaction rental, selection for expedited delivery via a subscription service, etc.) by one or more users108, and/or valuation data associated with the historical and/or snapshot data. Jobs228may also include system components useful for generating recommendations presented by fulfiller/hosting entity devices202. As an example, these recommendations may be presented, via one or more fulfiller entity devices118, to recommend one or more articles to a fulfiller entity120that are available for transaction rental integration, but not yet integrated (e.g., not currently made available in a storefront associated with a hosting entity136).

Jobs228may also include, for example, periodic data refresh operations, periodic synchronization states among internal and external services, and automated tasks to run in the background at internal system206, as described in more detail below with respect to job execution cluster346(FIG. 3). Additional jobs for internal system206for supporting other aspects of a CaaS may include, for example, ETL (extract, transform, and load) processes that comprise collecting data from multiple different sources, converting the collected data to other one or more preset formats as necessary, and loading the data into the target database(s) (e.g., data warehouse systems230). Additional system components useful for jobs of environment200may include, for example, replenishment identifier (RID) generation service(s), size advisor data set, size advisor algorithmic preparation component(s), recommendation service(s) for generating recommendations to end users, search data sets, etc.

Internal system206may include file stores or databases that store snapshots, which may include the above-described snapshot data. Snapshots may include information that represents a status, at a particular moment or over a period of time, of information created, collected, and/or stored by architecture200and in particular, by data storage systems226. For example, snapshots associated with inventory integration systems may be stored in inventory data storage systems226, which may be included in one or more virtual private clouds or one or more physical private networks. Snapshots stored in systems226may include data representative of a current status of pooled articles, including articles that are allocated for the article integration service. Other snapshots may capture states of other aspects of internal system206and may be stored in systems226or in one or more additional data stores. Additional snapshots may capture settings, files, configurations, and the memory state of the components of the internal system206.

These snapshots may be restored upon request or scheduling, and when a snapshot is restored, settings, and/or the state of the internal system206may be returned to the states they were in at the time the snapshots were captured. Internal system206may include third party data ETL processes which may collect data from different external sources (e.g., external systems212), convert the collected data to other one or more preset formats, and load the data into one or more target databases.

Internal system206may include the data warehouse systems230in one or more virtual private clouds or one or more physical private networks. As discussed above, data warehouse systems230may include one or more target databases for ETL processes that collect data from various sources (e.g., external systems212or inventory exchange data storage systems226). Data warehouse systems230may then utilize the collected data as, for example, parameters for business intelligence that reveals patterns, analytics, and insights for implementing an article integration service. In particular, data warehouse systems230may store information useful for performing analytics for the article integration service, such as identities and roles of entities engaged in the service, articles currently offered in the integration service, articles that are currently shared (“pooled”) among two or more inventory services, etc. Analytics may be performed, based on information of data warehouse systems230, by components of internal system206(e.g., inventory management jobs228) and/or with one or more external systems212.

Analysis of information stored in data warehouse systems230may be used for one or more reporting tools useful for monitoring the performance of one or more entities (fulfiller entities, hosting entities) and/or one or more articles involved in the article integration service. For example, such analyses may be useful for the generation and presentation of information representative of performance analytics of one or more articles offered for selection via the article integration service, performance analytics of one or more storefronts presenting articles offered for selection via the article integration service, performance analytics of a particular entity (e.g., performance of a fulfiller entity's inventory listed in a hosting entity's storefront), the performance of one or more particular roles (e.g., a group of fulfiller, hosting, or other entities), etc.

With continued reference toFIG. 2, environment200may also include user devices204, which may correspond to user devices112(FIG. 1). Users108of the CaaS electronic platform may use the user devices204to access the internal system206, as recipients of the services provided by the components of the internal system206(e.g., as potential users of transaction rental systems and/or as subscribing users that receive articles offered as a service). For example, users108of user devices204may be one or more registered subscribers who physically receive and wear items that are distributed via the CaaS electronic platform (e.g., subscribers of a service offered in connection with a fulfiller entity120). As shown inFIG. 2, user devices204may access the internal system206via external user facing applications208. External user facing applications208may be browser-accessed web pages or web-based applications that include web-based user interfaces accessible from one or more user devices204over one or more networks (e.g., one or more networks101).

In some implementations, web application hosting server210acts as an intermediary for enabling communications made between devices202and internal system206, between employee devices and internal system206, and between user devices204and internal system206. Internal system206may present different communications interfaces (e.g., applications) based on an identity supplied by devices202and204, such as a tenant or other entity, employee, or user. In particular, internal system206may further provide different communications interfaces based on a particular role supplied by entity devices202(e.g., a role corresponding to fulfiller entities120, hosting entities136, or additional or hybrid entities146).

Web application hosting server210may be an external (e.g., third party) server or internal (e.g., intranet, local network) server or host that provides an online platform for the article integration service. Web application hosting server210may host a platform for an article integration service that may be accessed by devices202. This integration service may provide a management interface (e.g., via inventory assignment portal332, described below) for viewing, selecting, and modifying articles or groups of articles that are available for use in the integration service. These interfaces, supporting systems and processes (e.g., components of environment200and/or server system300), which are collectively or individually referred to herein as a “inventory availability and valuation service,” may facilitate the ability of entities (e.g., a fulfiller entity120), to provide one or more articles that are available for transaction rental in a storefront of another entity (e.g., a hosting entity136).

When web application hosting server210communicates with user devices204of one or more users108(e.g., subscribing and/or non-subscribing users of a CaaS provider), web application hosting server210may present a web-based storefront interface integrating online retail components (e.g., an online point-of-sale system) onto the storefront interface. Web application hosting server210may communicate with the internal system206(e.g., the API endpoints218, the APP endpoints220, a device202or204logged into the internal system206), to retrieve necessary information about the internal system206, and to generate or dynamically update an interface for user devices204to interact with the storefront, the storefront allowing user devices204to select one or more articles as part of a subscription service, for a one-time purchase, and/or for a transaction rental interaction.

Each of the interfaces accessed by devices202via applications for inventory sharing216may be dynamically-updated by web application hosting server210. Applications216may allow entity devices204to communicate with internal system206and with one or more external systems212to facilitate the operation and update of the management and retailer storefront interfaces that are generated, at least in part, based on information provided by the article integration service. Information, including information for the inventory availability and valuation service for inclusion in one or more retailer storefronts, may be supplied via API access communication links250that enable communication with external systems212.

External systems212may be configured to perform data analytics or other tasks that support operations performed with inventory availability and valuation services224and/or inventory management jobs228. For example, external systems212may include one or more analytics system236, payment systems238, external storefront hosting systems240, and value setting systems242.

Analytics systems236may include computing resources in communication with one or more components of internal system206to collect, store, and/or manage data and analytics associated with the one or more entities120,136,146. Analytics systems236may be located remotely from the internal system206(e.g., at tenant servers, servers of other entities, external cloud servers, etc.). Analytics systems214may communicate with the components of internal system206using API access or file transfer link250over one or more networks101. For example, analytics systems214may communicate with the API endpoints218of internal system206, or receive files from third party data ETL processes. Data provided for analysis by analytics systems236may include data stored in inventory integration data storage systems226and/or data warehouse systems230. Analytics systems214may be accessed by employee devices202, which may correspond to employee devices116or entity devices118,132,142(FIG. 1). Analytics systems236may be accessed by devices202to retrieve analytics data for business intelligence (e.g., by identifying articles that perform well, as indicated by transaction rental selections, closeting selections, try then buy selections, and/or purchase selections).

Payment systems238may facilitate payments from users to entities and, if desired, between entities, as part of the article integration service. Payment systems238may, for example, facilitate payments for an article selected for transaction rental by a user interacting with a storefront of a hosting entity136, in a manner that facilitates involvement of a fulfiller entity120and/or an additional entity146, as described below. Payment systems238may provide a payment tool in the form of a cloud-based platform configured to accept payments from entities with a website or within the platform's mobile application. Payment systems238may generate invoices and/or reports based on a relationship between a plurality of entities. For example, for a pair of entities including a fulfiller entity120and a hosting entity136, payment systems238may be configured to review articles selected by a user for a transaction rental interaction and generate reports and/or invoices by calculating an apportionment of funds that are distributed between these entities according to the result of a transaction rental lifecycle (e.g., initial fees, daily rental fees, purchase fees, etc.) for a particular article. Payment systems238may be accessed by devices202to retrieve payments and view payment analytics data.

External storefront hosting systems240of external systems212may include one or more entity-housed systems and/or cloud systems that host websites, applications, etc., for presenting one or more storefronts for hosting entities136, as described below with respect toFIG. 5. External storefront hosting systems240may facilitate hosting of websites and/or applications that present a user interface that allows one or more users interacting with user devices204to select one or more articles for purchase. External storefront hosting systems240may be in communication with one or more internal systems206via API access250to share data associated with the articles offered via the electronic storefront, and to allow inventory services224and inventory management jobs228to manage inventory availability to determine whether one or more articles (e.g., articles of a pooled inventory) are available for transaction rental integration with the external storefront. While external storefront hosting systems240may be included in external systems212(e.g., at tenant servers or other entity servers), in some configurations of environment200, external storefront hosting systems240may instead be implemented, either partially or entirely, within internal system206(e.g., hosted within internal system206and accessed via external user facing applications208).

Value setting systems242may include one or more interfaces and/or analytics services that determine (set) a value associated with an article offered in, for example, storefront of a hosting entity136provided via external storefront hosting system240. Value setting systems242may be in communication with internal system206(e.g., inventory services224, inventory management jobs228) via API access250to communicate one or more of an e-commerce price (e.g., a suggested or original price, a current or real-time price) and an article identifier (e.g., a unique identifier, a SKU, or other information indicative of article characteristics such as color, size, style, manufacturer, etc.).

Environment200may include data and analytics systems214configured to analyze and present information relevant to an article integration service, or other aspects of environment200. Data and analytics systems214may include computing resources in communication with one or more components of internal system206that collect, store, and/or manage data and analytics associated with the one or more entities120,136,146. One or more systems or components of data and analytics systems214may be located remotely from the internal system206. Data and analytics systems214may communicate with one or more components of internal system206using API access or file transfer link254over one or more networks101(FIG. 1). For example, data and analytics systems214may communicate with API endpoints218of internal system206, or receive files from third-party data ETL processes. Data and analytics systems214may be accessed by devices202, and, which may correspond to entity devices118,132,142(FIG. 1), and, if desired, to employee devices116.

The number and arrangement of devices, components, and communication networks shown inFIG. 2are provided as an example. In practice, there may be additional devices, components, and/or communication networks, fewer devices, components, and/or communication networks, different devices, components, and/or communication networks, or differently arranged devices, components, and/or communication networks than those shown inFIG. 2. Furthermore, two or more devices shown inFIG. 2may be implemented within a single device, or a single device shown inFIG. 2may be implemented as multiple, distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment200may perform one or more functions described as being performed by another set of devices of environment200.

III. Server System

FIG. 3is a diagram showing the architecture of an exemplary server system300for facilitating an inventory availability and valuation service, e.g., for providing one or more articles for selection via transaction rental integration. Server system300may correspond to server system102depicted inFIG. 1, and to internal system206depicted inFIG. 2.

Server system300may be accessed by a plurality of entities having different roles, such as users306(e.g., non-subscribing users and/or subscribing users of the CaaS electronic platform), hosting entities308, fulfiller entities310, additional entities312, and employees of the CaaS electronic platform, such as warehouse staff314. Each of these entities may access server system300via authentication and access control302.

Users306may correspond to users108(FIG. 1). Users306may use computing devices (e.g., user devices204) to access the server system300, as recipients of the CaaS electronic platform services provided by the components of the server system300. For example, users306may be one or more non-subscribing users (registered or un-registered) and/or registered subscribing users who closet or otherwise select one or more articles by reviewing storefront catalogs of one or more entities, and physically receive and wear the apparel that are distributed via the CaaS operations. Users306may log in to, or otherwise interact with, server system300to initiate tasks associated with one or more CaaS operations, such as, for example, account management, storefront catalog viewing, selecting one or more articles for rental transactions, closeting items, providing return notifications, etc.

Fulfiller entities310may correspond to fulfiller entities120, while hosting entities308may correspond to hosting entities136. Additional entities312may have characteristics of both a fulfiller entity310and a hosting entity308. Thus, additional entities312may correspond to additional entities146, as well as to one or more fulfiller entities120and/or hosting entities136.

Fulfiller entities310may include entities whose physical inventory of articles is at least partially made available and offered via the article integration service. This physical inventory may include one or more “pooled” inventories, or inventories that are provided for multiple service types. For example, a pooled inventory supplied by a particular fulfiller entity310(or, if desired a CaaS operator or CaaS tenant) may include one or more articles available for transaction rentals. One or more of the articles available for transaction rentals may also be included as part of a subscription service of a CaaS, and, in particular, a “real-time” inventory associated with the CaaS. Such an inventory may be available for selection by one or more CaaS users (e.g., to guarantee that an upcoming shipment provided as part of the subscription service includes an expedited article). Thus, a “pooled” article may be made available to one or more users306as an article available for expedited handling as part of a subscription service, and also available for selection via a storefront of one or more hosting entities308for a transaction rental service that integrates articles from a fulfiller entity310, additional entity312, etc., with a storefront of one or more hosting entities308. While fulfiller entities310may offer articles to subscribing users306, if desired, one or more fulfiller entities310may provide articles via another entity (e.g., hosting entities308and/or additional entities312) without directly offering any articles to users306.

Hosting entities312may include entities that provide a storefront having one or more articles listed for purchase and/or for subscribing users. Hosting entities312may for example, provide articles for purchase and may not have an existing system for transaction rental services. Thus, hosting entities312may employ the physical inventory or inventories offered by fulfiller entities310and additional entities312to provide one or more articles for transaction rental services, as described below.

Additional entities312may act as both hosting entities308and fulfiller entities310, depending on the role of the entity312in a particular interaction. Thus, additional entities312may offer one or more articles via an electronic storefront for purchase and/or as part of a subscription service, and may offer one or more articles for transaction rentals on the storefront of another additional entity312or a hosting entity308via an inventory availability and valuation service.

Warehouse staff314may correspond to employees114and other users of devices116, and may access a warehouse operation portal340or other portals to support CaaS operations, as described below. Warehouse staff314or other employees114may log in to server system300and, via warehouse portal340or other portals may initiate, view, manage, enter data in, or perform administrative tasks related to warehouse and other operations.

In order to control access to server system300, entities306-314may communicate with authentication and access control component302, which may grant access to the server system300only if the access-requesting entity is successfully authenticated based on the access control conditions corresponding to the particular entity. Access control conditions may be stored in a memory in communication with server system300, and may be applied to a particular entity based on various entity-specific factors, such as, for example, the authorized role(s) of each entity, the device being used by each entity, the portal sought to be accessed, and/or the geographic location of each entity.

External services318may be services associated with tenant-specific storefronts (e.g., storefronts322associated with a tenant for offering articles as a service). Services318may provide, for example, customer support services, marketing and advertisement services, content management systems for building and updating each tenant-specific storefront, and analytics services for tracking and reporting the performance of the tenant-specific storefronts.

External services320may include services that are configured for use with inventory integration (e.g., inventory integrated by use of inventory availability and valuation service224) with one or more of entities308,310,312. These external services320may include, for example, valuation services for hosting a storefront associated with article purchases (e.g., external storefront hosting systems240), managing valuations of articles listed via the article integration service (e.g., value setting systems242) and analytics services (e.g., analytics services236) for analyzing and reporting performance of storefronts and/or articles listed via the article integration service (e.g., analytics representative of the frequency with which articles are selected for transaction rental by users306, average valuations of these articles, etc.).

Tenant storefront322may include storefronts be accessed by users306for purchasing or closeting articles included in one or more storefront catalogs, and may include web-based user interfaces. In particular, tenant storefront322may include a different interface for each tenant, such as a storefront interface324A unique to tenant A, a storefront interface324B unique to tenant B, and a storefront interface324N unique to tenant N. Each tenant-specific interface may include a shared core324common to all tenants. Tenant storefront322may communicate with other components of server system300(e.g., external services318, per tenant catalog CMS328, and/or microservices356) using storefront combination API326. Each tenant storefront322may present a plurality of articles for purchasing, closeting and/or selection of articles by users306. These articles may include one or more articles that are provided by an article integration service.

Tenant storefront322may be accessed by users306for selecting articles, and may include web-based user interfaces. In particular, tenant storefront322may include a different interface for each tenant, such as a storefront interface324A unique to tenant A, a storefront interface324B unique to tenant B, and a storefront interface324N unique to tenant N. Each tenant-specific interface may include a shared core324common to all tenants. Tenant storefront322may communicate with other components of server system300(e.g., external services318, per tenant catalog CMS328, and/or microservices356) using storefront combination API326. Each tenant storefront322may present a plurality of articles available for closeting. In some aspects, tenant storefront322may correspond to storefronts for purchasing articles and/or for selecting articles, by users306.

Entities308,310,312may access per tenant catalog content management system (CMS)328. The per tenant catalog CMS328may comprise a portal that includes one or more user interfaces for communicating with entities308,310,312to create, modify, and/or update one or more apparel catalogs for the tenant storefront322(e.g., storefront catalogs in the storefront interface324A for tenant A as part of an article subscription service). Per tenant catalog CMS328may be in communication with the external services318. External services318may include online storefront management services, including subcomponents such as a storefront user interface building/updating tool and a dashboard for managing sales operations as orders, payments, and/or shipping. Data maintained by one or more of the external services318may also be communicated to the per tenant catalog CMS328. Communication between per tenant catalog CMS328and external services318may be performed by, for example, storefront combination API326, and/or data exchange over the one or more networks101.

Entities308,310,312may each access inventory assignment portal332. Inventory assignment portal332may allow fulfiller entities310and additional entities312to designate one or more articles that are available via the inventory availability and valuation service. Inventory assignment portal332, or one or more separate portals, may also allow hosting entities308to browse articles designated by entities310,312, and to select one or more these articles for transaction rental integration via an electronic storefront associated with the hosting entity308.

At the server system300, warehouse staff314may access a warehouse operation portal340. Warehouse staff314authorized for such access may be one or more employees associated with warehouse operations of the CaaS electronic platform of the server system300. Warehouse portal340may include one or more user interfaces at which warehouse staff314may, for example, initiate, view, manage, enter data in, or perform administrative tasks related to warehouse operations. The warehouse portal340may communicate with microservices356, including, for example, warehouse APIs370. Warehouse APIs370may include service components that may communicate with the warehouse operation portal340may include, for example, order processing, item photoshoot, inventory, inventory location, garment allocation, order fulfillment, shipping label management, package and shipment operations, return processing, laundry, and cycle count.

Warehouse APIs370may facilitate the management of physical inventories that are located in one or more distribution centers, such that a particular warehouse may include articles that are shared between a plurality of entities among entities308,310,312. Warehouse APIs370may facilitate the management of article allocation via one or more databases, for example. Data for a particular shared article that is managed via warehouse APIs370may identify each entity that is sharing the article, the entity that supplied the article, and other data stored in data warehouse390(and in inventory allocation database480,620, described below).

Portals332and340may communicate with one or more components of microservices356, and/or external services318,320, via one or more suitable APIs and/or over the one or more networks101. Suitable APIs may include, for example, APIs access communication links250and/or254(FIG. 2). In at least some configurations, portals332and/or340may correspond to applications for inventory sharing216, external systems212, or both (FIG. 2).

Within server system300, a group of hosts (e.g., computing resources) may form a job execution cluster344. Job execution cluster344may utilize the combined computing power and shared resources of the hosts to process one or more jobs (e.g., workloads) of server system300. Job execution cluster344may, for example, dynamically allocate the combined computing power and the shared resources of the hosts, to perform one or more jobs associated with storefront, back office, and article integration tasks. For a plurality of different jobs, the allocation of the computing power and the resources may be prioritized based on predetermined criteria, such as, for example, criticality, cost, time/order of receipt, and/or urgency. Job execution cluster344may be configured to execute inventory integration jobs345, storefront jobs346, and back office jobs348.

Inventory exchange jobs345may configure job execution cluster344to perform background tasks triggered by one or more actions of entities308,310,312and/or actions of users306. Actions of entities308,310,312may trigger background tasks by an interaction with portal332. For example, if a hosting entity308selects one or more articles offered for integration from a supplied inventory of a fulfiller entity310(e.g., for inclusion in a transaction rental service integrated with an electronic storefront of hosting entity308), inventory integration jobs345may perform tasks, such as initiating one or more microservices356and calling one or more APIs corresponding to microservices356. Actions of users306that trigger inventory integration jobs345may include viewing a storefront of a entity308,312, that is associated with an inventory availability and valuation service, and interacting with one or more graphical elements associated with a particular article or group of articles. As an example, a user306may view an article that is available for purchase on an externally-hosted storefront of a hosting entity308. In response, inventory integration jobs345may perform background tasks to determine whether a corresponding article is available via an article integration service, a corresponding transaction rental value of the article, etc. These tasks may include calling one or more APIs corresponding to microservices356, including APIs associated with external storefront358, inventory reservation360, account362, real-time (“RT”) valuation364, status monitoring366, and/or targeting368. Additionally or alternatively, job execution cluster344may call one or more external service components of services320.

Storefront jobs346may configure job execution cluster344to perform background tasks triggered by actions of users306at tenant storefront322(e.g., a storefront of a CaaS for subscribing users associated with one or more entities308,310,312), such as initiating an order for one or more garments for shipment to a first user. In response to such an action by a user306, job execution cluster344may execute a series of tasks under storefront jobs346, including initiating one or more microservices356, including warehouse APIs370. Inventory exchange jobs345and storefront jobs346may be performed on demand at server system300, whenever tenant or user actions are received via portal332and/or via tenant storefront(s)322.

Back office jobs348may configure the job execution cluster344to perform tasks such as periodic data refresh350, periodic synchronization states352, and automated background tasks354. In some implementations, back office jobs348may correspond to, or include, inventory management jobs228(FIG. 2). Job execution cluster344may execute jobs scheduled under periodic data refresh350, in accordance with one or more predetermined data refresh schedules. During each iteration of a job under periodic data refresh350, applicable variable data (e.g., metrics, scores, recommendation outputs, prices, etc.) stored in databases associated with data warehouse390may be refreshed based on the values of the input parameters captured at the time of execution. For example, periodic data refresh350may refresh the values and/or data associated with the article integration service, such as inventory allocation and/or assignment, article valuation, etc. Periodic data refresh350may also refresh values and/or data associated with subscribing user functions, such as matching and fulfillment operations, pricing, achievable service level (ASL) and item retirement, discovery and recommendation, and other data science jobs.

Job execution cluster344may also execute one or more jobs scheduled under periodic synchronization states352. For example, a job under periodic synchronization states352may synchronize states between microservices356and external states (e.g., external services318and320). Job execution cluster344may execute jobs scheduled under automated background tasks354, such as tasks triggered from portal332based on actions of entities308,310,312. A job under automated background tasks354may also be generated in response to an action of one or more employees such as warehouse staff314interacting with warehouse operation portal340.

Server system300may include microservices356that are available for deployment, for example, via one or more APIs. Microservices356may correspond to inventory integration services224depicted inFIG. 2. Microservices356may be services hosted at the virtual private clouds, as shown inFIG. 2, and may include external storefront358, inventory reservation360, account362, RT valuation364, status monitoring366, targeting368, and warehouse APIs370. While individual microservices358-370are shown inFIG. 3, as understood, one or more of these microservices may be combined, or may be accomplished by one or more additional microservices.

External storefront358may facilitate communication between one or more externally-hosted storefronts associated with hosting entities308and/or additional entities312. External storefront358may be configured to communicate with, for example, an electronic commerce (e-commerce) storefront hosted externally of server system300. External storefront358may include service components, such as APIs, configured to receive an article identifier associated with an internal or external storefront (e.g., an article viewed by a user306interacting with the storefront). External storefront358may facilitate identification of an article associated with the article identifier, identification of an allocation of one or more physical articles available for transaction rental selection, and identification of a transaction rental valuation associated with the article.

Inventory reservation360may be configured to initiate API calls to identify and update a reservation status of specific article(s) that are identified by via API calls initiated by external storefront358. Reservation status of an article may include updating and/or reading a flag indicative of whether a particular physical article is available for transaction rentals. Inventory reservation360may be initiated when a user interacts with a storefront and thus initiates one or more components of the inventory availability and valuation service, and may temporarily reserve an article while a user completes a transaction rental interaction.

Account362may include service components such as, for example, new account creation, password login, social network login, password reset, single sign-on function(s), and/or session renewal function(s). These service components may be activated by users306for accessing storefronts322, entities308,310,312for accessing per tenant catalog CMS328, inventory assignment portal332, or by warehouse staff314for accessing warehouse operation portal340. Account362may facilitate identification of users306and may support identification of a user type. For example, by authenticating a user306, account362may facilitate identification of a user status or classification, such as a non-subscribing user, a subscribing user, a new user, etc.

RT valuation364services may include service components for assigning one or more of an initial transaction rental value, a daily transaction rental rate, a Try-Then-Buy price, a buy item price (e.g., a discounted TTB price), or other values associated with an article provided via the inventory availability and valuation service. These service components may initiate communication with value setting systems242or, when value setting systems242are included in internal system206, may include components for calculating appropriate values for one or more articles offered via the inventory availability and valuation service.

Status monitoring366may include one or more service components for determining status of one or more articles offered via the inventory availability and valuation service. In particular, one or more microservices for status monitoring366may include service components for monitoring status of articles that were selected via an the inventory availability and valuation service by users306. Status monitoring service366may enable operations including, for example, monitoring a lifecycle status of an article that is in the possession of a user306(e.g., data indicative of whether a particular physical article is in an initial transaction rental period, a daily transaction rental period, etc.). Status monitoring service366may support operations for enabling users306to view current and previously-rented articles, costs associated with these rentals, and current status of rented articles that were supplied by the inventory availability and valuation service and/or by an article subscription service.

Targeting services368may include one or more service components that retrieve (e.g., from account service362) a user identifier or other characteristic associated with a user306interacting with an internal or external storefront. Targeting services368may be configured to transmit an instruction for generating a transaction rental call-to-action (CTA) based on an article identified via external storefront services358and/or the user306identified via external storefront services358. For example, targeting services368may include service components for performing prioritization for determining which users of users306are presented with a transaction rental CTA based on the identity and/or characteristic of these users306, an identity of a storefront that a particular user306is interacting with, or other targeting criteria, as described below.

Warehouse APIs370may include service components such as, for example, order processing, photoshoot (e.g., capturing electronic images of articles being made available for rental or purchase transactions), warehouse inventory (e.g., computer-implemented functions associated with inventory management of items to be rented or purchased), warehouse location (e.g., locating item in a warehouse), fulfillment (e.g., fulfilling initiated orders), shipping label (e.g., generating, modifying, or outputting shipping labels), package and shipment (e.g., computer-implemented functions associated with packaging, sorting, and/or delivering the shipments out to users306), return processing (e.g., processing return items that have been received at a warehouse), laundry (e.g., computer-implemented functions associated with performing laundry of the returned items), and/or cycle count (e.g., computer-implemented functions associated with counting cycles that each wearable item have gone through).

Microservices356may be in communication with a plurality of databases, including, for example, databases included in data warehouse390. Data warehouse390may include one or more data repositories that are dynamically updated based on tenant interactions with per tenant catalog CMS328, portals332,340, etc. Data warehouse390may also include dynamically updated data repositories that reflect interactions of users306with one or more storefronts, including the interactions of users306to select articles made available for transaction rental via the article integration service and/or articles provided for transaction rental via a pooled inventory of articles.

At server system300, an ETL system (not shown) may extract, transform, and load various data outputs into data warehouse390, so that data warehouse390may serve as a unified source of data that are used for business intelligence or business analytics, including analytics indicative of the performance of the inventory availability and valuation service. For example, the ETL system may collect data from multiple different sources, convert the collected data to preset formats, and load the data into the data warehouse systems390. In some implementations, the data warehouse390may correspond to the data warehouse systems230(FIG. 2).

As shown inFIG. 3, data warehouse390may be in communication with a report server391. Report server391may be an external data visualization engine which may be configured to collect data from data warehouse390and generate reports focused on business intelligence and analytics. Reports may be scheduled and/or automated with preconfigured settings (e.g., applicable time periods, input parameters, output metrics, output format, etc.), to produce reports395. Additionally, or alternatively, ad hoc requests may be received from one or more entities308,310,312, such that report server391may respond to the ad hoc requests by generating and communicating reports395. Reports395may present information indicative of a performance of aspects of the inventory availability and valuation service, including the performance of articles or groups of articles, performance of storefront(s) that present articles via the inventory availability and valuation service, or performance of one or more entities308,310,312.

The number and arrangement of devices, components, and communication networks shown inFIG. 3are provided as an example. In practice, there may be additional devices, components, and/or communication networks, fewer devices, components, and/or communication networks, different devices, components, and/or communication networks, or differently arranged devices, components, and/or communication networks than those shown inFIG. 3. Furthermore, two or more devices shown inFIG. 3may be implemented within a single device, or a single device shown inFIG. 3may be implemented as multiple, distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) associated with server system300may perform one or more functions described as being performed by another set of devices associated with server system300.

IV. Exemplary Article Integration Service Implementations

FIG. 4Ais a diagram illustrating an exemplary implementation of environment100, architecture200, and/or server system300for operating an article integration service430that, if desired, may be associated with a CaaS platform. Implementation400is simplified and exemplary.

Implementation400may enable functionality that allows entities, such as a plurality of hosting entities and a plurality of fulfiller entities, to integrate transaction rental features into independent storefronts and to provide transaction rental functionality in a manner that reduces the amount of development and testing required to deploy transaction rental functions. As shown inFIG. 4A, one or more articles404of an inventory402associated with a fulfiller entity420(which may correspond to entities120,146,310,312), may be integrated via inventory availability and valuation service430with a storefront of a hosting entity410(which may correspond to entities136,146,308,312).

In the exemplary implementation400, a fulfiller entity420(having an exemplary entity ID0587) may be associated with an inventory402that includes a plurality of articles404that were supplied (e.g., manufactured or purchased and transferred to a warehouse, such as a warehouse associated with a CaaS operator, for distribution to one or more users416). Articles404of inventory402may include one or more articles that have been used in one or more previous usage cycles. For example, articles404may include articles that have been previously shipped to, and returned by, one or more users416. Users416may correspond to users108,306, and may include subscribing users associated with a tenant of the CaaS and/or subscribing users of one or more fulfiller entities420.

A hosting entity410(having an exemplary entity ID1678) may be associated with an inventory452that includes a plurality of articles454, each of the articles454being included in a physical inventory that is made available for users418via an electronic storefront of hosting entity410(e.g., an external storefront for purchasing articles454). These articles454may each be excluded from a subscription service and/or from a transaction rental service or other service(s) for temporary use of articles454. Users418may correspond to users108,306, and include one or more subscribing users associated with a CaaS. In particular, one or more users418may be a subscribing user associated with a subscription service of tenant and/or a fulfiller entity420.

In some embodiments, one or more hosting entities410(an exemplary entity410having an entity ID9342inFIG. 4A) may offer articles solely from other entities, without the need to acquire or supply a physical inventory. For example, a hosting entity410may offer articles from one or more fulfiller entities420(one such entity410being shown inFIG. 4A). These hosting entities410may act as aggregators that offer articles for sale and for transaction rentals without physically providing articles to the CaaS. As aggregators, such entities410may offer articles physically supplied by a plurality of different fulfiller entities420. If desired, such hosting entities410may be associated with one or more storefronts that are constituted entirely by articles from other entities. These articles may include solely articles available for transaction rentals, if desired.

An allocation database480may include data sets for allocating articles of inventories402,452. Allocation database480may enable the operation of article integration service430through real-time management of article reservations, as described below. Information corresponding to each inventory402,452may be created, stored, and dynamically updated in one or more inventory allocation databases480, which may correspond to one or more databases associated with data warehouse390, data warehouse systems230, and/or databases106.

Inventory availability and valuation service430may enable a user418interacting with a hosting entity410to select an article404that is supplied by fulfiller entity. Inventory availability and valuation service430may be configured to integrate at least a part of inventory402of fulfiller entity420with a storefront of hosting entity410. In particular, service430may enable one or more articles404that correspond to (e.g., share a SKU, color, size, and/or style) an article of inventory452to be offered as part of transaction rental service enabled in a storefront of a hosting entity410by inventory availability and valuation service430. Thus, one or more articles404supplied by fulfiller entity420may be included in articles492of a physical shipment490physically shipped based on a user's interaction with the storefront of hosting entity410. In some aspects, each of articles404and454may be located in the same physical location (e.g., a single logistics center or warehouse). However, if desired, one or more of articles404and454may be present at different physical locations, such as warehouses, before these articles are supplied to a user.

FIG. 4Bis a diagram illustrating an exemplary transaction rental sequence. As shown inFIG. 4B, as a first Step440, a transaction rental CTA (e.g., transaction rental CTA524shown inFIG. 5and described below) may be presented on a storefront of a hosting entity. This may include enabling inventory availability and valuation service430in a step468. In particular, this CTA may be presented when an article viewed on the hosting entity storefront matches a corresponding article460associated with a fulfiller tenant, this corresponding article460of the fulfiller tenant being available for a transaction rental service. A user may select CTA524and complete a transaction rental process (e.g., by interacting with an electronic interface associated with the fulfiller entity).

A step444may include shipping or otherwise dispatching the article to the user. This may be performed by packing462the requested article by itself or with one or more additional articles. Once the requested article is delivered to the user's requested destination, the user may experience the article464for a period of time. If desired by the user, the article464may be purchased. When the article is not purchased and is returned466, the returned article466may be received by the fulfiller tenant (or an associated CaaS operator) and may be processed (e.g., inspected, cleaned, and transferred to a storage location). This may replenish the article, allowing an update to the availability of the replenished article460.

V. Exemplary Article Integration Service Implementations

FIG. 5is a diagram illustrating an exemplary storefront environment500implemented via environment100, architecture200, and/or server system300. Environment500may include one or more graphical elements that are presented via user device112. These graphical elements may, for example, allow a user to interact with an electronic storefront, such as a storefront of a hosting entity410.

A user interacting with an electronic storefront may be presented with a plurality of articles as graphical elements, such as an article image510. Additional article information may be presented via article description512. The article description may include information associated with article image510, such as style information, an article name, a manufacturer, etc. Environment500may also include values514,516(e.g., values indicative of a purchase price of article510), category (e.g., style) selectors518, characteristic selectors520, purchase call-to-action (CTA)522, transaction rental CTA524, and transaction rental value526.

One or more values514,516, associated with article510may be accessed in real time (e.g., when environment500is generated, e.g., in response to an a user making an initial selection of article510from a storefront presenting a plurality of articles). For example, RT valuation364microservice (FIG. 3) may be initiated to retrieve value514and/or value516via an API (e.g., API access250) in communication with one or more systems (e.g., external services318, external storefront hosting systems240) that host the electronic storefront associated with environment500. A value514may correspond to an initial value set by hosting entity410, a recommended value associated with article510, or similar value assigned to article510when article510is initially offered. A value516may be a current value that is set on demand by hosting entity410. Value514, value516, or both, may be set with value setting systems242such that RT valuation364is configured to retrieve an updated value as necessary in real-time or near-time. RT valuation364may retrieve one or both values514,516by initiating an API call to communicate with an external system. In some configurations, RT valuation364may be initiated periodically (e.g., hourly, daily, weekly, etc.), instead of retrieving value514,516in real-time.

A user may, by interacting with environment500, select a desired article category by changing the selected category selectors518and a desired article characteristic (e.g., size) by changing the selected characteristic selector520. Purchase call-to-action (CTA)522may allow a user to begin a process for purchasing article510according to the selected category and characteristic.

Transaction rental CTA524may be a dynamically-generated graphical element implemented via microservices356, and may be generated according to actions (e.g., API calls) or other service components of external storefront358, inventory reservation360, account362, RT valuation364, and/or targeting services368. Transaction rental CTA524may be generated by taking a plurality of factors into account, including an identity of the user interacting with environment500(e.g., as determined via account362), an availability of an article in a pooled inventory determined via inventory reservation360, a valuation determined via RT valuation364, and a desired subset of users that are eligible for transaction rental services determined via targeting services368. An API, such as external storefront358may cause transaction rental CTA524to be included in environment500. In response to a change initiated by an interaction with one or both of a category selector518and characteristic selector520, inventory reservation360may be initiated to determine whether a fulfiller's inventory (e.g., inventory402) includes an available article that matches the newly-updated category and characteristic. Thus, transaction rental CTA524may be updated in real-time or near real-time, and may be omitted from environment500when no article is available that matches the updated category and/or characteristic.

Account362may facilitate an identification or category of the user interacting with environment500. This identity may be compared to a desired or targeted category of users via targeting services368. For example, Transaction rental CTA524may be presented with the identified user is a subscribing user associated with a CaaS. In addition to users having a desired subscription status, categories of users that may be targeted for a transaction rental CTA524may include, first-time users and/or new users (e.g., a user that created an account and/or joined a subscription service within a predetermined period of time such as one month, two months, three months, six months, one year, etc.). Targeted users may include, for example, users associated with a CaaS (e.g., a subscribing user) that does not have a subscription with the hosting entity and fulfilling entity associated with a particular transaction rental interaction, prior users of a transaction rental service, etc. Users may be targeted based on the value of previously-rented articles. For example, targeted users may include users that rented at least one article having a value equivalent to, or below, a particular value, users that rented at least one article having a value equivalent to, or above, a particular value, users whose cumulative activity is less than a particular activity level (e.g., a particular cumulative spend, a particular cumulative number of articles and/or transaction rental interactions), and/or users whose cumulative activity is greater than a particular activity level.

An transaction rental value526may be presented in environment500together with transaction rental integration transaction rental524. Transaction rental value526may indicate a value associated with initiating a one-time rental of article510. In some aspects, transaction rental value526may be generated, in real time, based on the value(s) identified with RT valuation364. In one example, RT valuation364may extract one or both values corresponding to values514,516, and determine a numerical value526as a function of values514and/or516. For example, value526may be determined by retrieving a current valuation of article510via RT valuation364, and generating a value presented as transaction rental value526as a percentage of the retrieved current valuation. In addition to presenting a transaction rental CTA524based on these or other characteristics of the user, targeting services368may modify value526based on the same or similar criteria as discussed above for targeting transaction rental CTA524. For example, a targeted user may be offered a discounted price to encourage users with relatively low activity to engage in the transaction rental service and/or to reward high-volume or high-value customers.

VI. Storage System Configuration

FIG. 6is a diagram illustrating an exemplary storage system for information stored in an allocation database620, which may correspond to one or more of allocation database480, data warehouse390, or data warehouse systems230. Inventory allocation database620may store information600in one or more data stores representative of inventory allocation information for one or more articles. In particular, information600may include unique article identifier (“AID”) data602that identifies a group of articles having the same characteristics (e.g., articles having the same SKU), unique entity identifier (“EID”) data, and data representative of an inventory that each article is allocated to, as allocation data604(an example of an assigned category). Information600may further include permission information606,608,610(e.g., in the form of binary flags) indicative of whether an article is permitted for distribution on behalf of one or more respective hosting entities (e.g., HE1, HE2) and/or fulfiller entities (e.g., FE1). Real-time availability (“RTA”) data612of information600stored in allocation database(s)620may indicate whether a particular physical article is available (e.g., located at a warehouse and not currently in possession of a user) for shipment to the user interacting with environment500(FIG. 5). Related article ID (“RAID”) data614may indicate one or more articles that are related to another article. Articles identified in RAID data614may provide a substitute article that is presented (e.g., displayed in environment500) to offer a different article for a transaction rental when the currently-viewed article is not associated with any item currently in a RT inventory, as described below.

Each unique AID stored in data602may correspond to a particular article or group of articles that are substantially identical (e.g., articles that share the same SKU, color, size, style, manufacturer, etc.). Each individual article or group of articles may be assigned or otherwise allocated to an inventory group. As an example, one or more articles may be allocated to a real-time availability or “RT” inventory. Articles in the RT inventory (indicated by the flag “RT” inFIG. 6), may be available for transaction rentals. These articles may be available for one or more services in addition to a transaction rental service. For example, articles in the RT inventory pool may be available for one or more subscribing users as part of a subscription service. In particular, articles in the RT inventory pool may be available for a first service, the transaction rental service, as well as a second service, such as an expedition service of a CaaS offered for subscribing users to enable these users to select one or more articles for expedited processing and handling. Articles that are not allocated to the RT inventory pool may be reserved for use solely in a particular service, such as one or more subscription services. This reserved status is indicated by a reserved flag represented by “RES” inFIG. 6.

Information600may include data indicative of associations between article identifiers602and specific entities. This data may indicate when each article can be included as an inventory of a respective entity. Thus, “Y” entries represent an article that is permitted to be included in a storefront of the corresponding entity, while “N” entries represent articles that are not permitted for inclusion in a storefront of the corresponding entity or otherwise unavailable.

Real-time availability (“RTA”) data612may be indicative of a current availability of a particular article for transaction rentals. RTA data612may be retrieved and updated, for example, by inventory availability and valuation service430in response to user interactions in environment500. RTA data612may be retrieved in response to a user viewing one or more articles presented in environment500, a user's selection of one or more articles presented in environment500, or other interactions. RTA data612may be updated, for example, in response to a user's interaction with transaction rental CTA524. When a user interacts with (e.g., selects) transaction rental CTA524, one or more microservices may update RTA data612. In particular, when a user selects transaction rental CTA524, an API, such as an API or other service component of inventory reservation360(FIG. 3), may update RTA data612to reserve a particular article identified in AID data602while a user interacts with environment500. For example, an article that is initially indicated as being available (“Y”) in RTA data612may be marked as unavailable (“N”) in RTA data612. When a user completes a process for selecting the article for shipment (e.g., as a part of a transaction rental), inventory reservation360may be marked as unavailable until the article is received and processed by a CaaS provider following use of the article by the user.

When an article that corresponds to a currently-viewed article (e.g., article510) is not available, RAID data614may be accessed to determine whether one or more similar articles are available. The similar articles may have one or more shared characteristics with article510, such as a shared color, style, size, manufacturer, etc. When a viewed article (e.g., an article associated with AID 1234-WTE-4) is indicated as being unavailable in RTA data612, a transaction rental CTA may be presented for a related article (e.g., with information corresponding to articles of AID 2050-PTN-5 in the example shown inFIG. 6).

VIII. Exemplary Method for Managing Electronic Inventory Data

FIG. 7is a flowchart showing an exemplary method700for managing data associated with wearable articles, according to one or more embodiments. Prior to the below-described steps, method700may include physically receiving one or more articles in a warehouse or logistics center from one or more entities, such as a fulfiller entity. These articles may be processed, cleaned (if necessary), and stored so as to be available for shipment to one or more subscribing users. One or more of these articles may be provided for temporary use by one or more users, returned, processed (e.g., inspected, cleaned, and stored) before again being made available as part of an inventory available for transaction rentals, as part of one or more pooled inventories for example.

As shown in the exemplary method700, a server system (e.g., server system102or server system300) may receive wearable article data from one or more electronic interfaces (e.g., via tenant catalog CMS328, inventory assignment portal332, and/or or applications for inventory management216). This wearable item data may describe one or more wearable items, and/or other articles, made available for physical shipment to users via electronic transactions, wherein the one or more electronic interfaces are accessible from one or more devices (e.g., entity devices118,132,142or employee devices116) over one or more networks (Step702). The wearable item data may describe one or more wearable items, and/or other articles, that are available via an inventory availability and valuation service430. The inventory availability and valuation service430may allow one or more tenants to make use of articles from other entities for inclusion in transaction rental offerings.

Additionally, the server system (e.g., the server system102or the server system300) may host one or more electronic interfaces (e.g., applications for inventory management216and/or inventory assignment portal332), the inventory assignment portal332being responsive to actions performed with the electronic interfaces. The server system may be configured to, in response to these actions, create, modify, or delete article data (e.g., inventory data included in databases106, inventory integration data storage systems226, data warehouse systems230, data warehouse390, allocation database480, and/or allocation database620) for integrating one or more articles across a plurality of storefronts.

The server system (e.g., the server system102or the server system300) may assign a category to articles described in the article data. The article category may be one of a plurality of categories that correspond to service(s) for offering and distributing physical articles described in the article data. For example, a first category may indicate that corresponding articles are available for selection by a first plurality of users (e.g., articles available for purchase in a first storefront). An exemplary second category may be assigned to articles to indicate that these articles are available for selection by a second plurality of users (e.g., articles available as part of a subscription service that is limited to subscribing users) (Step704).

The server system may monitor availability data for one or more wearable articles included in the article data (e.g., availability data included in databases106, inventory integration data storage systems226, data warehouse systems230, data warehouse390, allocation database480, and/or allocation database620). Availability data (e.g., RTA data612) may indicate whether one or more articles is available for selection via a first electronic storefront (e.g., a storefront associated with a first entity), a second electronic storefront (e.g., a storefront associated with a second entity), or both (Step706). The availability data may be dynamically updated (e.g., in real time) according to selections made by a user interacting with the first electronic storefront, the second electronic storefront, or an additional storefront.

The server system (e.g., the server system102or the server system300) may initiate one or more services (e.g., microservices356) to facilitate physical shipment of the first article (Step708). This article may be one or more articles that were supplied to a logistics center or warehouse by a second entity (e.g., a fulfiller entity120,310,420), and may be selected by a user interacting with the first electronic storefront associated with a first entity (e.g., a hosting entity136,308,410).

AlthoughFIG. 7shows example blocks of an exemplary method700, in some implementations, the exemplary method700may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG. 7. Additionally, or alternatively, two or more of the blocks of the exemplary method700may be performed in parallel.

FIG. 8depicts an exemplary computer device or system, in which embodiments of the present disclosure, or portions thereof, may be implemented. In some implementations, server system102, user devices112, employee devices116, entity devices118,132, and/or142, entity devices202, user devices204, internal system206, external systems212, server system300, and/or any other computer system or user terminal for performing the various embodiments of the present disclosure, may correspond to device800. Additionally, each of the exemplary computer servers, databases, user interfaces, modules, and methods described above with respect toFIGS. 1-7can be implemented in device800using hardware, software, firmware, tangible computer readable media having instructions stored thereon, or a combination thereof and may be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination of such may implement each of the exemplary systems, user interfaces, and methods described above with respect toFIGS. 1-7.

If programmable logic is used, such logic may execute on a commercially available processing platform or a special purpose device. One of ordinary skill in the art may appreciate that embodiments of the disclosed subject matter can be practiced with various computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, computer linked or clustered with distributed functions, as well as pervasive or miniature computers that may be embedded into virtually any device.

For instance, at least one processor device and a memory may be used to implement the above-described embodiments. A processor device may be a single processor, a plurality of processors, or combinations thereof. Processor devices may have one or more processor “cores.”

As shown inFIG. 8, a device800used for performing the various embodiments of the present disclosure (e.g., server system102, user devices112, employee devices116, entity devices118,132,142, entity devices202, user devices204, the internal system206, the external system(s)212, server system300, and/or any other computer system or user terminal for performing the various embodiments of the present disclosure) may include a central processing unit (CPU)820. CPU820may be any type of processor device including, for example, any type of special purpose or a general-purpose microprocessor device. As will be appreciated by persons skilled in the relevant art, CPU820also may be a single processor in a multi-core/multiprocessor system, such system operating alone, or in a cluster of computing devices operating in a cluster or server farm. CPU820may be connected to a data communication infrastructure810, for example, a bus, message queue, network, or multi-core message-passing scheme.

A device800(e.g., server system102, user devices112, employee devices116, entity devices118,132,142, entity devices202, user devices204, internal system206, external system(s)212, server system300, and/or any other computer system or user terminal for performing the various embodiments of the present disclosure) may also include a main memory840, for example, random access memory (RAM), and may also include a secondary memory830. Secondary memory, e.g., a read-only memory (ROM), may be, for example, a hard disk drive or a removable storage drive. Such a removable storage drive may comprise, for example, a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive in this example reads from and/or writes to a removable storage unit in a well-known manner. The removable storage unit may comprise a floppy disk, magnetic tape, optical disk, etc., which is read by and written to by the removable storage drive. As will be appreciated by persons skilled in the relevant art, such a removable storage unit generally includes a computer usable (e.g., computer-readable) storage medium having stored therein computer software and/or data (e.g., instructions).

In alternative implementations, secondary memory830may include other similar means for allowing computer programs or other instructions to be loaded into device800. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units and interfaces, which allow software and data to be transferred from a removable storage unit to device800.

A device800may also include a communications interface (“COM”)860. Communications interface860allows software and data to be transferred between device800and external devices. Communications interface860may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface may be in the form of signals, which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface860. These signals may be provided to communications interface860via a communications path of device800, which may be implemented using, for example, wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels.

The hardware elements, operating systems and programming languages of such equipment are conventional in nature, and it is presumed that those skilled in the art are adequately familiar therewith. A device800also may include input and output ports850to connect with input and output devices such as keyboards, mice, touchscreens, monitors, displays, etc. Of course, the various server functions may be implemented in a distributed fashion on a number of similar platforms, to distribute the processing load. Alternatively, the servers may be implemented by appropriate programming of one computer hardware platform.

Throughout this disclosure, references to components or modules generally refer to items that logically can be grouped together to perform a function or group of related functions. Like reference numerals are generally intended to refer to the same or similar components. Components and modules can be implemented in software, hardware, or a combination of software and hardware. The term “software” is used expansively to include not only executable code, for example machine-executable or machine-interpretable instructions, but also data structures, data stores and computing instructions stored in any suitable electronic format, including firmware, and embedded software. The terms “information” and “data” are used expansively and includes a wide variety of electronic information, including executable code; content such as text, video data, and audio data, among others; and various codes or flags. The terms “information,” “data,” and “content” are sometimes used interchangeably when permitted by context.

It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.