Patent Application
20250045715
Examples herein relate generally to a multi-tenant licensing and subscription management. More specifically, but not by way of limitation, embodiments relate to systems, methods, and media for enabling an interactive management platform and providing convenient user interfaces for subscription and license management. Examples provide highly-configurable features for incorporating enhanced technology in the form of convenient platform tools and applications for licensing and subscription management in a multi-tenant network.
User interfaces and data structures pertaining to the management of subscriptions and license fees (e.g., for goods or services), while having advanced in recent years, have not been optimized for use in a cross number of verticals and also for the management of more complicated subscription arrangements between providers and customers in a multi-tenant network.
One prior art system for providing subscriptions to a bundle of services, and more specifically channels from a program guide, is described in U.S. Pat. No. 7,596,797 (the '797 patent). Here, a terminal controller is used to select a bundle of channels based on a subscription matrix of a user. However, the technology described in the '797 patent is inflexible, lacks configurability by a service provider and also provides a limited set of options for an end-user or consumer.
In some examples, a multi-tenant licensing and subscription management system includes a processor and a memory storing instructions that, when executed by the processor, configure the licensing and subscription management system to perform operations including providing, for a tenant practice in a multi-tenant network, an interaction platform for receiving, via a platform user interface, health-related subscriptions from a tenant patient, the platform including a suite of invokable tenant-selectable features for processing data relating to the subscriptions and/or operations of the tenant practice, including, in the platform user interface, a first toggle feature selectable by the tenant practice to toggle between a tenant practice view flow and a tenant patient view flow, via an interface in the tenant practice view flow, receiving from a tenant practice, a selection of one or more of the tenant-selectable features, calculating a tenant-configurable practice license fee based on the selection of one or more of the tenant-selectable features, accessing first order data relating to a first subscription offering to the tenant patient, the first order data including a first set of attributes relating to the first subscription offering, accessing second order data related to a second subscription offering to the tenant patient, the second order data including a second set of attributes related to the second subscription offering, combining the license fee and the first and second order data into a licensing and subscription data structure that includes quantity data and period data for each of the first and second subscription offerings, calculating a combined one-time payment amount for both the first and second subscription offerings based on the quantity data, calculating a combined periodic monthly subscription payment amount for both the first and the second subscription offerings based on the quantity and period data, causing presentation, in a user interface in the tenant patient view flow, of both the combined one-time payment amount and the combined monthly subscription payment amount, and causing presentation, in a user interface in the tenant practice view flow, of the tenant-configurable practice license fee.
The licensing and subscription management system may also include where the presentation in the tenant patient view includes presentation of a first user interface element to present the combined one-time payment amount and a second user element to present the combined monthly subscription payment amount, and presentation of a second toggle feature to toggle between the presentations of the first and second user interface elements.
The licensing and subscription management system may also include where the operations further comprise receiving third order data relating to a third offering, the third offering having a one-time payment option only, where the presentation includes a presentation of a one-time payment amount related to the third offering in conjunction with each of the combined one-time payment amount and the combined monthly subscription payment amount.
The licensing and subscription management system may also include where each of the first and second set of attributes includes an item identifier associated with at least one of an item or a service included in the offering.
The licensing and subscription management system may also include where each of the first and second set of attributes includes a recurring attribute identifying the respective offering as being recur offering, and where the combining of the first and second order data is performed based on each of the first and second subscription offerings being identified as recurring offerings.
The licensing and subscription management system may also include where the operations further comprise communicating the combined monthly subscription payment amount from the licensing and licensing and subscription management system to a financial exchange system, the financial exchange system operating to present financing options relating to the combined monthly subscription payment amount to financiers.
The licensing and subscription management system may also include where the suite of invokable tenant-selectable features includes one or more of a catalog concierge, a membership status, an instant promotion, a tenant practice insight, a tenant patient insight, a tenant patient import, a tenant patient checkout, a next day funding, a card present payment status or checkout flow, a card not present payment status or check out flow, a risk monitoring option or status, a dispute management tool, a tenant practice onboarding tool, a tenant patient onboarding tool, a multi-location payment tool, a multi-device payment tool, a license fee and subscription management tool, a payment operations analysis, a device management tool, and a PCI compliance monitoring tool.
The licensing and subscription management system may also include where the communication of the combined monthly subscription payment amount includes communicating further information pertaining to each of the first and second subscription offerings, the further information including identification information for a provider of the subscription offering, and identification information for a consumer of the subscription offering.
The licensing and subscription management system may also include where the operations further comprise receiving, at the financial exchange system, a financing offer related to at least one of the first or the second subscription offerings, the financing offer including financing terms, and further include communicating the financing offer from the financial exchange system to the licensing and licensing and subscription management system for presentation to a consumer.
The licensing and subscription management system may also include where the financing offer includes both a first financing offer pertaining to the first subscription offering and a second financing offer pertaining to the second subscription offering.
The licensing and subscription management system may also include where the licensing and licensing and subscription management system automatically applies predefined business rules to the first and second financing offers in order to selectively present at least one of the first or second financing offers to the consumer. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
Such examples can provide solutions for technical problems because creating and managing licensing and subscription programs across many different tenants, each with their own systems and requirements, requires solving many technical challenges around integration, data management, and configuration. Examples described herein solve these challenges by providing a licensing and subscription management system that can be configured for each tenant's needs.
Allowing each tenant to have a unique licensing and subscription program requires a technical solution that can be flexibly configured and customized for each tenant. The inventive subject matter solves this by allowing each tenant or patient to provide ‘order data’ to configure their specific licensing and/or subscription program.
Providing an interface that is fast and easy to use requires solving technical challenges around user experience design and system performance. The inventive subject matter solves this by using ‘a touchscreen tablet device’ and allowing ‘the customer’ (e.g., a tenant practice or a tenant patient) to configure the licensing and subscription program while watching.
Executing licensing and subscription programs in real-time during payment transactions requires technical solutions by integrating an interactive platform with payment processing systems and calculating aspects such a subscription fees, licensing fees, and loyalty rewards, on-the-fly. The inventive subject matter solves this by operating ‘in conjunction with or as part of a payment facilitator’. So in summary, the inventive examples described herein can solve these technical problems by providing a multi-tenant licensing and subscription management system including an interactive platform that can be configured for each tenant's needs, allows flexible customization of each tenant's program, uses an easy-to-use touchscreen interface, and integrates with payment processing to execute licensing and subscription programs in real-time. The examples thereby enable the creation and management of unique licensing and subscription programs for many different tenants with technical ease.
According to some further example embodiments, there is provided a licensing and subscription management system that generates and uses data structures and interfaces that allow for configurability and flexibility in the creation of a bundle of subscriptions, for a specific consumer, to one or more products or services, which may be delivered in terms of one or more plans. Payment for the bundle of subscriptions, products or services may be made using a “card present” transaction. Sometimes these payments can fail due to system failure, or insufficient source funds for example. A paying user might try the payment again using another source of funds in the hope the payment goes through. Occasionally, a payment might go through twice. As mentioned above, this uncertainty, lack of information, and potential payment duplication is not helpful to the user, or a shop assistant or staff member helping the payer to pay for the bundle, product or service. Some examples herein generate an alert based on a detection that multiple payments are being issued for the same purchase, in order to prevent multiple payments being collected for the same purchase. Examples seek to provide a technical solution assisting users to prevent re-running multiple payments for the same purchase, either inadvertently or due to system glitches.
Each subscription within a bundle of subscriptions can be for a product or service and has a fulfillment price. Further, each subscription has a period in which it may recur (e.g., one month, six months, one year, etc.). These recurrence periods may perpetuate indefinitely or may terminate after a set number of occurrences (or cycles).
Each subscription can furthermore be financed by a loan from a third party, or by a service provider. Alternatively, a consumer can pay the full amount for a subscription at one time (e.g., upon initiation of the subscription). The terms of the subscription (both delivery and financial) can be dynamically managed by consumers in some cases (e.g., a consumer may be able to change the. It over which the subscription may reoccur).
Even further, each subscription may be executed independently of other subscriptions in a bundle, while billing for one or more subscriptions within the bundle may be aggregated into a single payment once a month (or on some other periodic basis). Service plans may, in some embodiments, be made with the assistance of a service delivery expert (e.g., a physician), and may be fulfilled at a place of business of the expert (e.g., a medical practice office of the physician). Product fulfillment, on the other hand, may be performed by shipment.
As noted above, each subscription in a bundle may be financed by a loan from a third party or service provider. In one embodiment, loans may be facilitated in real time. To this end, a licensing and subscription management system communicates details of a particular subscription to a financial exchange in near real-time. The details of a particular description include, for example, identification of the products or services being offered, details of the provider, and details of the consumer. Third-party financiers may access the financial exchange, again in near real-time, to accept any number (or none) of the subscriptions being offered via the financial exchange.
In one embodiment, the receipt of subscription details, the offering of subscription financing opportunities to third-party financiers, and the receipt of acceptance/decline of a financing opportunity may occur in near real-time, and while a customer is standing at the checkout counter of a service consumer.
Defining the quantity and frequency of delivery of a product or service offering under subscription plan is tricky and presents technical challenges to a user. This is particularly so where the product or service offering is being subscribed to is part of a bundle of offerings or services included within a single subscription plan. For example, defining the quantity and frequency of delivery requires typing numerical data into appropriate fields and then calculating variables to display a monthly cost (or payment total) of the subscription plan. Because this area of the software is frequently used on a touchscreen tablet device while the customer is watching, now there is a need to have a fast friction free device to enter the data.
The client device 108 is accessed by a user 118 and processes operations and applications (e.g., a browser application, or commercial platform) sourced from or associated with a tenant 120. Where applicable in context, the user 118 may also be referred to as a client, a customer, a consumer, or a tenant patient in some examples herein. Where applicable in context, the tenant 120 may also be referred to as a service provider, a medical practice, or a tenant practice, in some examples herein. A tenant practice may for example operate in a group of networked tenant practices in a multi-tenant network 100. The user 118 may be a tenant patient of the tenant practice, for example. The tenant device 110 is accessed and operated by the tenant 120 to host and process tenant operations and tenant applications 122. In some examples, the multi-tenant network 100 includes a great multiplicity of tenants 120, each communicatively coupled with the licensing and subscription service 106.
The application servers 104 include an API server 124 and a web server 126 which, in turn, facilitate access to several application components 128 that include an expert system 130, a licensing and subscription management system 132, a financial engine system 134, and a data aggregator and anonymizer 136. Each of these components is provided with a respective API, namely an API 138, an API 140, an API 142, and an API 144.
The application components 128 are communicatively coupled to database servers 146 which in turn facilitate access to one or more databases 148.
In an example scenario, a tenant 120 (e.g., a medical practice) may wish to provide offerings (e.g., products or services) to a user 118 (e.g., a patient of the medical practice), either as a once-off/one-time delivery or as part of a subscription plan which has a recurrence. In this example, the medical practice, i.e., tenant 120, may also wish to provide the patient, i.e., user 118 with the option of paying for a health product or consultation as a once-off payment, as a subscription payment, or as a combination of a once off payment and a subscription payment.
At a high level, the expert system 130 operates to enable an expert in a particular vertical (e.g., the medical practice or tenant 120) to its patients or users 118. An expert system 130 is accordingly specifically constructed and programmed for the creation of a plan for the delivery of a specific product or service in a particular product or service vertical. The expert system 130 may also assist to define and manage a licensing plan for a tenant 120 involving a tenant-configurable practice license fee based on a selection of a number of invokable tenant-selectable features of an interaction platform described further below.
The licensing and subscription management system 132 is responsible for the automated management of a plan (which may or may not include any number of subscriptions to products or services, or licensing fees).
The financial engine system 134 is responsible for communicating financing opportunities related to a plan to one or more financiers (e.g., who may operate as a provider, or who may be a third party accessing the financial engine system 134 via the third-party applications 116).
In some examples, the financial engine system 134 may include or be connected to a payment processing system 4500 discussed further below in relation to
Some examples herein generate an alert based on a detection that multiple payments are being issued for the same purchase in order to prevent multiple payments being collected for the same purchase. Examples thus seek to provide a technical solution assisting users to prevent re-running multiple payments for the same purchase, either inadvertently or due to system glitches.
The licensing and subscription management system 132 operationally calculates and presents information relating to overall options related to a subscription for bundled purchase, a license fee for example, a tenant-configurable practice license fee for bundled platform features selected from a suite of platform features described further below. The financial engine system 134 operationally allows third parties (e.g., lenders) to view financing opportunities and accept or reject such financing opportunities for subscriptions (or bundles of subscriptions) and license fees generated by the licensing and subscription management system 132.
As illustrated, the processor 206 is communicatively coupled to both the processor 202 and processor 204 and receives data from the processor 202, as well as data from the processor 204. Each of the processor 206, processor 202, and processor 204 may host one or more of an expert system 130, a licensing and subscription management system 132, a financial engine system 134, and a data aggregator and anonymizer 136.
The licensing and subscription management system 320 is also communicatively coupled to a database 308 to both store and retrieve data needed by each of the payment processing and billing system 302, the fulfillment system 304 and the notification system 306. The fulfillment system 304 creates and tracks the fulfillment or delivery of a service or a product. For example, for a service, the fulfillment system 304 records what was rendered or provided (e.g., what, how much, when, value) and uses the notification system 306 to remind users of appointments for a follow-up service. For products, the fulfillment system 304 issues orders, tracks shipping and delivery, in addition to tracking what was rendered and provided.
The notification system 306 is a messaging system that uses different media or messaging channels (e.g., email, text, push notification, etc.) to alert customers, providers (e.g., practices) and operations of different events.
The customer application 402, via the API server 124 and the communications network 102, is also able to access customer's merchant 404 and customer's member 406. The application component 128 is also shown to exchange information and data with payment processors 408, financing processors 410 and product manufacturers 412.
The licensing and subscription management system 400 is, in one example embodiment, a cloud-based e-commerce solution built for developers to streamline and shorten the time to market of any e-commerce system that implements a variety of tenant licensing fees and arrangements, subscription models, quotations, recurring billings, electronic payments, order financing, order fulfillment, loyalty program, and notifications. The licensing and subscription management system 400 provides a rich set application programming interface (API) for developers to seamlessly integrate with their own systems. Modules and their APIs that developers can use to customize the licensing and subscription management system 400 to meet their own needs are as follows:
A subscription 506 furthermore has associated financing 516. A subscription 506 may be financed via a loan or via a service provider directly as part of the service provider's subscription business. Alternatively, a subscription 506 may be fulfilled at the time of ordering.
Attributes of the subscription 506 may be managed by customers in some cases. For example, the cycles 514 may be modified or changed by a customer using the client 150 in order to interact with the licensing and subscription management system 320.
A specific subscription 506 may furthermore be executed independently of any other subscriptions included in a set of subscriptions 504, with the exception that billing is aggregated to a single payment at predetermined intervals (e.g., once a month).
A plan 502 may also include a license fee 518 (also referred to as a tenant-configurable practice license fee) based on a set of selectable platform features 520 selected by a tenant 120 using the licensing and subscription management system 132 or licensing and subscription management system 320 in a multi-tenant network 100.
A plan 502 for the delivery of service may be constructed or defined with the help of an expert (e.g., a physician or doctor) using an appropriate expert system 312, and performance/delivery of a subscription 506 of the plan 502 may be fulfilled at the expert's place of business (e.g., the doctors practice). A plan 502 for the delivery of a product may be fulfilled by shipment from a third party.
To facilitate financing (e.g., a loan as part of the financing 516) in near real-time, the licensing and subscription management system 320 is communicatively coupled to the financial engine system 134 to enable the licensing and subscription management system 320 digitally to communicate details about a particular subscription 506 or set of subscriptions 504 or license fee 518 or set of selectable platform features 520 to the financial engine system 134. Financiers then access the financial engine system 134 (e.g., using a third-party application 116) to optionally accept a financing offer relating to a particular set of subscriptions 504 or subscription 506, or license fee 518 or set of selectable platform features 520.
This facilitation of financing by a financier happens in near real-time for a tenant 120 or user 118. In a typical scenario, a customer is physically present at the checkout counter of a service provider. To this end, the financial engine system 134 operationally aggregates accepted financing and rates, refusals and regular recurring subscriptions amounts to create a quote for a total monthly price for all subscriptions within a set of subscriptions 504.
Fulfillment records (e.g., indicating and recording whether a particular subscription 506 has been fulfilled) are stored within fulfillment tables 614.
The method 1100 commences at operation 1102 with the presentation of plan options to a customer. In one embodiment, the presentation may be made via user interfaces on which an expert (e.g., a cosmetic physician) and the customer collaborate. The presentation may accordingly be done via interfaces that are generated and communicated from an appropriate expert system 124, via a web server 122, to a client device 108 being operated by the expert.
At operation 1104, the licensing and subscription management system 128 receives plan configuration data from the expert system 124, the plan configuration data having been received from the customer at operation 1104 and in response to the presentation of plan options at operation 1102. The plan configuration data, in some example embodiments, include the data described above with reference to
At operation 1106, the licensing and subscription management system 128 proceeds to automatically and dynamically create a subscription plan data structure, such as that described above with reference to
At operation 1108, the licensing and subscription management system 128 initiates a financing checkout process by communicating pertinent details of a particular plan 502 of the financial exchange 130. Specifically, the licensing and subscription management system 128 provides the following information to the financial exchange 130:
Details of the plan including an array of subscriptions.
The financial exchange 130 responds with a number of financing offers containing:
The licensing and subscription management system 128 will consider these and pick zero or more to offer the customer using pre-defined business rules. These business rules may specify:
The financing checkout process is facilitated in real time as a customer may be physically present at the location of an expert (e.g., a physician). As described above, the financial exchange 130 then presents financing options to potential financiers (e.g., various third parties or to the expert or service provider), to enable real-time decision-making by the potential financiers.
At operation 1110, the financial exchange 130, having received acceptances or rejections of financing offers from the potential financiers, communicates these financing options back to the licensing and subscription management system 128, which in turn presents them, via the expert system 124 to the customer. The customer, at operation 1112, then elects to accept or reject the financing offers and finalizes the checkout process.
The method 1200 commences at operation 1202 with the receipt, by the licensing and subscription management system 128, of order data relating to a first subscription. The order data is inputted into an expert system 124 by a user (e.g., a customer in collaboration with expert, or by an expert alone) and specifies various attributes with respect to a subscription (e.g., a product or service) that is being presented for purchase to a customer. Attributes of a subscription that may be included within the order data are reflected in the licensing and subscription table, offering table and catalog_item table of
At operation 1204, the licensing and subscription management system 128 may receive further order data relating to a second subscription that a particular customer wishes to purchase. Again, this further order data may be entered into the expert system 124 by a user, and specifies various attributes with respect to a second subscription.
Together, the first and second subscription may constitute a bundle of products and/or services that the customer wishes to purchase using either a one-time payment or a subscription payment plan.
After receiving the order data from a customer at operation 1202 and operation 1204, the expert system 124 operationally presents several subscription choices to a customer. The examples discussed herein with respect to subsequent figures show a process in which various cosmetic and/or beauty products and services are presented, by an appropriate expert system 124, to a user for selection. Multiple attributes of these subscriptions are specified in the order data received at operation 1202 and operation 1204, including attributes such as quantity (e.g., number of units), frequency or recurrence period (e.g., the period of time between the delivery of the respective quantity of products or services), and duration or cycles (e.g., the number of deliveries of the respective quantity or services).
At operation 1206, the licensing and subscription management system 128 combines the first and second order data into a subscription data structure (e.g., see
At operation 1208, the licensing and subscription management system 128 calculates a combined one-time payment amount for both the first and second subscriptions, based on quantity data included in the respective first and second order data.
At operation 1210, the licensing and subscription management system 128 calculates combined periodic monthly subscription payment amounts for both first and second offerings, based on the quantity, recurrence, and duration information included in both the first and second order data.
At operation 1212, the licensing and subscription management system 128 causes presentation of both the combined one-time payment amount, and the combined periodic monthly subscription payment amount, within a single user interface (see
The user interface includes a first user element to present the combined one-time payment amount (
While the combination of only first and second subscription offerings has been described above for the sake of clarity, multiple offerings subscriptions can be included in the subscription data structure. For example, third order data, relating to a third subscription offering, may be received via a user interface of an expert system 124 and communicated to the licensing and subscription management system 128. The licensing and subscription management system 128 may then combine the first, second and third order data into the subscription data structure.
At operation 1216, the licensing and subscription management system 128 receives the user selection of one of the payment options (e.g., a one-time payment or subscription payment), and dynamically creates a financial data structure related to the subscription bundle, based on the selected payment option. The financial data structure, which includes the subscription plan a data structure discussed above at operation 1106, is then used to initiate the financial checkout process (operation 1108).
The method 1200 then terminates at done block 1218.
A master catalog is a catalog of brand products and services that a specific supplier can choose from and modify to populate a user-specific and customized catalog. Following a login operation (
The creation of a new catalog item commences with the selection of the “create new item” menu item (
A user may then, from a drop-down menu, specify a unit type for the new catalog item (
A user then specifies a thumbnail image (
The above-described creation of a new catalog item for the master catalog is something that would typically only need to be performed one time to populate the master catalog. A user may furthermore review and edit a newly created master catalog item by selecting a within the “catalog list/all items” user interface.
Any of the information described above (e.g., the JPEG image, units, etc.) may conveniently be modified. A change or edit made to a single catalog item for a particular brand or manufacturer may, in some embodiments, automatically be propagated to other catalog items from the same brand or manufacturer. For example, a change to the thumbnail image of a particular catalog item from a particular brand may result in the thumbnail images for other catalog items from that same brand of manufacturer also being changed.
Each slider has a series of demarcations or intervals between a minimum value and a specified maximum value specified for the attribute. For example, a quantity slider 2404 has several demarcations representing a number or quantity of offerings that can be provided as part of the plan. Similarly, a recurrence period slider 2406 has a number of demarcations representing the number of months between each scheduled supply/delivery of the offering in terms of the plan.
Each slider also has a movable selection element in the form of a circle or dot, within which is displayed a number representing the value for the attribute that the expert wishes to specify as part of the plan. By sliding the movable selection item to the left and right, the expert is able to specify an input value for the respective attribute. This number is displayed as a numeric value within the movable selection item. Visually, the selection element is empty when located at the 0 value (the default position). Upon user selection, the selection element visually raises from a locked vertical position, to a vertical position just above the slider line. When in the move vertical position, the slider element is movable horizontally left and right along the slider line. The selection element is filled (or otherwise graphically distinguished) as it is moved from the default horizontal position. Further, a number or value is displayed within the selection element to represent the aligned value on the slider line. For example, in
As noted above, defining the quantity and frequency of delivery of a product or service offering under subscription plan is tricky and presents technical challenges to a user. This is particularly so where the product or service offering is being subscribed to as a bundle of offerings or services that are all being included within a single subscription plan. For example, defining the quantity and frequency of delivery requires typing numerical data into appropriate fields and then calculating variables to display a monthly cost of the subscription plan. Because the slider sub-interface 2402 is frequently used on a touchscreen tablet device while the customer is watching, there is a need to have a fast friction free device to enter the data.
The slider sub-interface 2402 described with reference to
The slider sub-interface 2402 also calculates and displays a monthly (or other periodic) cost dynamically as the respective sliders are manipulated. This function further increases the efficiency of the input and lets the user (e.g., the beauty expert or physician) and customer (e.g., patient) quickly adjust the sliders interactively to arrive at the desired cost.
This tool also allows for a volume discount model, so prices are adjusted accordingly without further interaction from the user. The base price for an offering (e.g., a service or product) is set in an offering table (see
In the illustrated example of
It will further be noted that the cart sub-interface 2502 includes all details regarding the subscription to the relevant product—e.g., three syringes, delivered every six months, and a subscription cost of $25 per month, with a $150 saving.
A lower part 2508 of the cart sub-interface 2502 provides a summary of offerings within the cart and shows a combined a subscription total of $25 a month, and a combined one-time purchase total of zero dollars, with a total payment due today in order to activate the subscription.
In the illustrated example of
As shown in
Referring to
In this way, a user (e.g., an expert) can conveniently present both the subscription option by selecting the subscription tab of the toggle element and the one-time payment option by selecting the one-time payment tab of the toggle element. Each of these tabs causes the presentation of the payment information to be updated and displayed in accordance with the selected payment option. A user (e.g., an expert) can thus conveniently communicate payment options to a customer (e.g., at a checkout) without having to make any modification to the content of the cart.
Referring to
Once the user is satisfied with the customer information, a “submit” button is selected, which then invokes a “review today's treatments” interface (
Further, “next appointment” fields for each offering may be populated to include a date for the next appointment (or delivery are an appropriate product and/or service). To this end, a convenient calendar drop-down (see
From the offering review interface, the sequence moves on to the payment information interface 3700 (
The payment information interface 3700 conveniently also allows a user to split the payment over multiple payment types, and accordingly input that only a portion of the payment total that is to be applied to a credit card, with the rest of the payment being paid in cash (or by check or other credit instruments). Once the payment information has been collected, the user selection of “next” button invokes the “payment received” interface 3800 (see
A user has the option of going back to the client list interface (see
The method 4200 commences at operation 4202, in which method 4200 presents, for a tenant practice in a multi-tenant network, an interaction platform for receiving, via a platform user interface, health-related subscriptions from a tenant patient, the presented platform including a suite of invokable tenant-selectable features for processing data relating to the subscriptions and/or operations of the tenant practice. The presentation may accordingly be done via one or more interface in a tenant practice view flow that are generated and communicated from an appropriate expert system 124, via a web server 122, to a tenant device 110 being operated by a tenant 120.
The tenant-configurable practice license fee may be considered in some examples as a “consideration” for the provision of configurable enhanced technology to the licensing and subscription management system 132 or licensing and subscription management system 320 operated by a tenant 120. A tenant 120 can select one of more the invokable tenant-selectable features to add technology and functionality associated with the selected invokable tenant-selectable features to their licensing and subscription management system (for example the licensing and subscription management system 132 or the licensing and subscription management system 320) and pay a tailored or configured license fee, accordingly. Unnecessary functionality for a given tenant 120 is not charged for or provided. Yet, as a tenant practice grows or becomes more sophisticated, for example, enhanced technology available through a fresh selection of the invokable tenant-selectable features is always on hand and can be configured by a tenant 120 accordingly.
A selection of a given invokable tenant-selectable features allows access to a respective application or tool that can be invoked by a tenant 120 to process data, or gain further insights into their practice, for example. The applications or tools may be run on one or more of the application servers 104 of
In some examples, incorporation of catalog management technology (for example to manage offerings, goods, and services and so forth) is possible by selecting catalog concierge 4304. A catalog management application becomes available to the tenant 120 to assist in configuring an online offering of goods and services and related charges, for example.
In some examples, a membership application can be incorporated by selecting a membership status 4306 from the suite 4346 of invokable tenant-selectable features.
In some examples, for instance as part of a marketing campaign, one or more selected goods or services in a configured catalog can be made the subject of an instant promotion by selecting the instant promotion 4308 from the suite 4346 of invokable tenant-selectable features.
In some examples, data analysis applications can be incorporated by selecting the tenant practice insight 4310 and/or the tenant patient insight 4312 from the suite 4346 of invokable tenant-selectable features.
Patient management applications can be incorporated in some examples by selecting the tenant patient import 4314 feature, and/or the tenant patient checkout 4316 feature, and/or the multi-location payment tool 4332 feature, and/or the tenant practice onboarding tool 4328, and/or the tenant patient onboarding tool 4330, from the suite 4346 of invokable tenant-selectable features.
Transactions of goods and services can be facilitated or analyzed in some examples by selecting respective applications associated with the next day funding 4318 feature, and/or the card present payment status or checkout flow 4320 feature, and/or the card not present payment status or check out flow 4322 feature, and/or the multi-device payment tool 4334, and/or the license fee and subscription management tool 4336, and/or the payment operations analysis 4338 feature, and/or the device management tool 4340 from the suite 4346 of invokable tenant-selectable features.
In some examples, aspects relating to risk management can be facilitated or analyzed by selecting respective applications associated with the risk monitoring option or status 4324 feature, and/or the dispute management tool 4326 feature, and/or the PCI compliance monitoring tool 4342.
In operation 4204, method 4200 includes, in the platform user interface (for example platform user interface 4302 of
In operation 4206, method 4200 via an interface in the tenant practice view flow (for example platform user interface 4302), receives from a tenant practice (for example tenant 120), a selection of one or more of the tenant-selectable features. In operation 4208, method 4200 calculates a tenant-configurable practice license fee based on the selection of one or more of the tenant-selectable features.
In operation 4210, method 4200 accesses first order data relating to a first subscription offering to the tenant patient, the first order data including a first set of attributes relating to the first subscription offering. In operation 4212, method 4200 accesses second order data related to a second subscription offering to the tenant patient, the second order data including a second set of attributes related to the second subscription offering. In operation 4214, method 4200 combines the license fee and the first and second order data into a licensing and subscription data structure that includes quantity data and period data for each of the first and second subscription offerings. In operation 4216, method 4200 calculates a combined one-time payment amount for both the first and second subscription offerings based on the quantity data. In operation 4218, method 4200 calculates a combined periodic monthly subscription payment amount for both the first and the second subscription offerings based on the quantity and period data. In operation 4220, method 4200 causes presentation, in a user interface in the tenant patient view flow (for example including the interfaces of
In operation 4222, method 4200 causes presentation, in a user interface in the tenant practice view flow (for example platform user interface 4302), of the tenant-configurable practice license fee (for example tenant-configurable practice license fee 4348 in
The method may also include where the presentation includes presentation of a first user interface element to present the combined one-time payment amount and a second user element to present the combined monthly subscription payment amount, and presentation of a second toggle feature to toggle between the presentations of the first and second user interface elements. The second toggle element may include one or more features of the toggle element described further above with reference to
The method may also include receiving third order data relating to a third offering, the third offering having a one-time payment option only, where the presentation includes a presentation of a one-time payment amount related to the third offering in conjunction with each of the combined one-time payment amount and the combined monthly subscription payment amount.
The method may also include where each of the first and second set of attributes includes an item identifier associated with at least one of an item or a service included in the offering.
The method may also include where each of the first and second set of attributes includes a recurring attribute identifying the respective offering as being recurring offering, and where the combining of the first and second order data is performed based on each of the first and second subscription offerings being identified as recurring offerings.
The method may also include communicating the combined monthly subscription payment amount from the licensing and licensing and subscription management system to a financial exchange system, the financial exchange system operating to present financing options relating to the combined monthly subscription payment amount to financiers.
The method may also include where the communication of the combined monthly subscription payment amount includes communicating further information pertaining to each of the first and second subscription offerings, the further information including identification information for a provider of the subscription offering, and identification information for a consumer of the subscription offering.
The method may also include receiving, at the financial exchange system, a financing offer related to at least one of the first or the second subscription offerings, the financing offer including financing terms, and further including communicating the financing offer from the financial exchange system to the licensing and licensing and subscription management system for presentation to a consumer.
The method may also include where the financing offer includes both a first financing offer pertaining to the first subscription offering and a second financing offer pertaining to the second subscription offering.
The method may also include where the licensing and licensing and subscription management system automatically applies predefined business rules to the first and second financing offers in order to selectively present at least one of the first or second financing offers to the consumer.
The method may also include where the suite of invokable tenant-selectable features includes one or more of a catalog concierge, a membership status, an instant promotion, a tenant practice insight, a tenant patient insight, a tenant patient import, a tenant patient checkout, a next day funding, a card present payment status or checkout flow, a card not present payment status or check out flow, a risk monitoring option or status, a dispute management tool, a tenant practice onboarding tool, a tenant patient onboarding tool, a multi-location payment tool, a multi-device payment tool, a license fee and subscription management tool, a payment operations analysis, a device management tool, and a PCI compliance monitoring tool. Other technical features may be readily apparent to one skilled in the art from the following figures, descriptions, and claims.
The point-of-sale server system 4408 provides server-side functionality via the network 4412 to a fraud detection client 4404. While certain functions of the point-of-sale system are described herein as being performed by either a fraud detection client 4404 or by the point-of-sale server system 4408, the location of certain functionality either within the fraud detection client 4404 or the point-of-sale server system 4408 may be a design choice. For example, it may be technically preferable to initially deploy certain technology and functionality within the point-of-sale server system 4408 but to later migrate this technology and functionality to the fraud detection client 4404 where a client device 4402 has sufficient processing capacity.
The point-of-sale server system 4408 supports various services and operations that are provided to the fraud detection client 4404. Such operations include transmitting data to, receiving data from, and processing data generated by the fraud detection client 4404. This data may include transaction data, customer data, product data, subscription data and provider data, as examples. Data exchanges within the point-of-sale server system 4408 are invoked and controlled through functions available via user interfaces (UIs) of the fraud detection client 4404.
Turning now specifically to the point-of-sale server system 4408, an API server 4414 is coupled to, and provides a programmatic interface to, application servers 4416. The application servers 4416 are communicatively coupled to a database server 4418, which facilitates access to a database 4420 that stores data associated with the transactions processed by the application servers 4416. Similarly, a web server 4422 is coupled to the application servers 4416 and provides web-based interfaces to the application server 4416. To this end, the web server 4422 processes incoming network requests over the Hypertext Transfer Protocol (HTTP) and several other related protocols.
The API server 4414 receives and transmits transaction data (e.g., commands and transaction data) between the client device 4402 and the application servers 4416. Specifically, the API server 4414 provides a set of interfaces (e.g., routines and protocols) that can be called or queried by the fraud detection client 4404 in order to invoke functionality of the application servers 4416. The API server 4414 exposes various functions supported by the application servers 4416, including account registration, subscription creations and management, the processing of transactions, via the application servers 4416, from a particular fraud detection client 4404 to another fraud detection client 4404.
The application servers 4416 host a number of server applications and subsystems, including, for example, a licensing and subscription server 4424 and a fraud detection server 4426. The licensing and subscription server 4424 implements functionalities for creating and managing subscriptions between multiple client devices 4402.
The fraud detection server 4426 provides functionalities for pre-declining fraudulent card transactions based on an evaluation of the transaction. Further details regarding the fraud detection server 4426 are provided below.
With reference to
In relation to fraud detection operations, the payment processing system 4500 may operate as or include a microservices depot including connections to one or more microservices databases, for example, including the illustrated microservice databases 4502, 4504, 4506, and 4508. The payment processing system 4500 and microservice databases may operate in a multi-tenant network 4510 including at least one tenant 120, as an example tenant (e.g., tenant 120 of
In some examples, the payment processing system 4500 includes a number of microsystems that each provide an associated microservice for a given tenant in the multitenant environment. Example microservices may include a point-to-point (P2P) encryption microservice (that writes to the microservice database 4502, for example), a global gateway microservice (that writes to the microservice database 4504, for example), a card microservice (that writes to the microservice database 4506, for example), and a payment microservice (that writes to the microservice database 4508, for example). Other microservices are possible.
In an example transaction, a patient at the tenant 120 swipes a card to pay for a product or service. Many other different types of transactions 4512 (such as sales (purchase), refunds, credits, loyalty program redemptions and so forth) may be received from any one or more of the patients at any one of more of the tenants in the multi-tenant network 4510. The numbers of patients and tenants can run into the thousands or even millions. It will be appreciated that the number, variety, and complexity of the transactions 4512 can be very high. In some examples, the payment processing system 4500 is configured to process this great multiplicity of transactions to check for fraud in near real-time.
When the example transaction is received at the tenant 120, at least one of the microservices in the payment processing system 4500 is invoked based on the nature or type of the transaction and writes out to its associated microservice database. As the transactions 4512 each proceed, each microservice database 4502-4508 collects its own related part of the transaction information; for example, the microservice database 4508 collects information for payment transactions (e.g., cash transactions), while the microservice database 4506 collects information for credit or debit card transactions. Other microservices are possible.
In some examples, the microservices depot includes a further microservice (not shown) called a ledger microservice. An associated ledger microservice database stores aspects related to transactional bookkeeping, recording aspects such as a transaction ID, a transaction dollar amount, details of an item, product or service purchased, and so forth. The ledger microservice operates as a ledger and keeps a tally of such details. The ledger information may be distributed or shared with all the other microservices.
In some examples, the data stored in microservice database 4502-4508 is transmitted (or otherwise made available) at operation 4514 to an “extract, load and transform” (ELT) tool, such as the illustrated ELT tool 4516. An example ELT tool 4516 may be (or include) a Matillion™ ELT tool 4516. For all of the microservices (including the ledger microservice), the ELT tool 4516 can perform ELT operations based on the continuous data supplied to it from the microservices databases 4502, 4504, 4506, and 4508, including, in some examples, the ledger microservice database.
In some examples, an output 4518 of the ELT tool 4516 includes normalized data or online transaction processing (OLTP) data that has been extracted, loaded, and transformed into star schemas and stored in a database, such as the Redshift database 4520. In some examples, the ELT tool 4516 extracts OLTP data, data from external online transaction processing databases, and data from any one or all of the microservice databases; loads the data; transforms this data into an abstracted, online analytical processing structure; and stores this as one or more star schemas in the Redshift database 4520.
In some examples, in parallel with the ELT process, the ELT tool 4516 also aggregates transactional information as part of its transformation, and then pushes at operation 4522 this aggregated data for storage in a Dynamo database 4524. In one sense, this operation may be considered to be moving information from what is a reporting infrastructure into a transaction processing resource. At operation 4526, the payment processing system 4500 and each of the microservices have access to this Dynamo database 4524 for fraud detection purposes and evaluation against near real-time aggregated information and ongoing real-time transactions 4512.
This aggregation of transactional data allows for the creation of fraud detection rules or threshold fraud parameters. Rules or threshold parameters may be based, for example, on an average monthly volume per practice for an individual practice (tenant) or patient. Other rules and thresholds are described further below in connection with machine learning with reference to
As opposed merely to providing fixed fraud detection rules or threshold parameters, some examples allow for dynamic rule setting and flexibility in configuration. Assume a new practice joins a medical network as an example multitenant environment. Here, based on the type of practice it is and based on what has been seen historically across sets of practices, examples allow different machine learning algorithms to predict what an average sales price for use as a fraud detection trigger might be for the new practice. The new practice can be immediately protected and “inherit” existing rules and threshold parameters, accordingly.
Examples can also predict that a purchase, for example a neurotoxin like Botox, includes a certain average reorder time or purchase frequency. A purported reorder transaction for the same product that is received in too short a time, or at an increased frequency, is potentially fraudulent. Based on such purchase patterns, fraud scores for a given transaction can be developed and processed, accordingly. This is described in greater detail below with reference to
In relation to payment deduplication functionality, some examples of a payment processing system 4500 herein generate an alert based on a detection that multiple payments are being issued for the same purchase of a subscription, item or service in order to prevent multiple payments being collected for the same purchase. Examples seek to provide a technical solution assisting users to prevent re-running multiple payments for the same purchase, either inadvertently or due to system glitches.
In this regard, the payment processing system 4500 includes at least one processor and a memory storing instructions that, when executed by the at least processor, cause the payment processing system 4500 to perform operations comprising detecting a card-present (CP) transaction request that comprises a set of CP transaction data, the CP transaction request relating to a purchase of an item or service and initiated by a card swipe or card tap made by human user (for example, user 118) at a Point-of-Sale tenant device 110 device operating at a tenant (for example a tenant 120) in a multi-tenant network (for example multi-tenant network 4510); accessing the CP transaction data; monitoring a flow of the CP transaction data across a plurality of communicatively-coupled CP transaction processing components, the CP transaction processing components including at least the tenant device 110, a federation layer 4530 executing between tenants 120 in the multi-tenant network 4510, a peer-to-peer encryption service 4532 accessible by the tenant device 110 and invoked by the CP transaction request, a gateway service 4534 acting as an exclusive contact point for the tenant device 110, and an application-support server (for example, application server 104) executing or processing data for a payment application to present at least some of the CP transaction data in a user interface of a mobile device (for example, client device 108) operated by the human user; detecting a failure or breakdown in the flow of monitored CP transaction data; detecting an attempted re-initiation of the CP transaction request for the same purchase of the item or service, the attempted re-initiation of the CP transaction request made after the detected failure or breakdown in the flow of monitored CP transaction data, the re-initiated CP transaction request including re-initiated CP transaction data; accessing the re-initiated CP transaction data; based on the detected re-initiation of the CP transaction request, comparing the CP transaction data against the re-initiated CP transaction data to identify an attempted duplicated payment for the purchase of the item or service; and based on the identified attempted duplicated payment, initiating a payment deduplication phase by generating a potential payment duplication alert for presentation at the tenant device 110 and/or in the user interface of the client device 108 operated by the human user.
In some examples, the operations further comprise, based on a response to the payment duplication alert, progressing the payment deduplication phase by voiding, or facilitating a voiding of, either one of the initial and re-initiated CP transaction requests. In some examples, progressing the payment deduplication phase further comprises processing a non-voided initial or re-initiated CP transaction request. In some examples, the response to the potential payment deduplication alert is received at the tenant device 110. In some examples, the response to the potential payment deduplication alert is received from the mobile device (client device 108) operated by the human user.
In some examples, comparing the CP transaction data against the re-initiated CP transaction data further comprises inputting the CP transaction data into a machine-learned model trained to analyze a set of historical transaction data, the set of historical transaction data having been aggregated from one or more historical data sources, the one or more historical data sources including at least one microservice database collecting a particular aspect of transactional data processed by a corresponding microservice of the tenant in the multi-tenant network; using an output of the machine-learned model to generate a transaction comparison fingerprint based on common or repeated tenant or human user payment transactions; storing the transaction comparison fingerprint in a transaction comparison fingerprint cache table, and monitoring a frequency or number of times the CP transaction data matches a transaction comparison fingerprint; comparing the CP transaction data against at least one transaction comparison fingerprint in the transaction comparison fingerprint cache table to generate a comparison result; and based on the comparison result, or the monitored frequency or number of matches, generating the potential payment duplication alert.
In some examples, monitoring the flow of the CP transaction data across the plurality of communicatively-coupled CP transaction process components includes monitoring for a failure or breakdown including at least one of a card decline, a network error, a request time out, a gateway time out, a failed response receipt, a bank error, a processor error, a lost connection, a power loss, a device reboot, and a device restart. In some examples, the tenant in the multi-tenant network is an aesthetic medical practice in a network of medical service providers, and wherein the human user is a patient at the aesthetic medical practice.
In some embodiments, different machine learning tools may be used. For example, Logistic Regression (LR), Naive-Bayes, Random Forest (RF), neural networks (NN), matrix factorization, and Support Vector Machines (SVM) tools may be used for classifying or scoring transaction data.
Two common types of problems in machine learning are classification problems and regression problems. Classification problems, also referred to as categorization problems, aim at classifying items into one of several category values (for example, is this object an apple or an orange?). Regression algorithms aim at quantifying some items (for example, by providing a value that is a real number). In some embodiments, example machine-learning algorithms provide a prediction probability to classify an image as digitally manipulated or not. The machine-learning algorithms utilize the training data 4602 to find correlations among identified features 4606 that affect the outcome.
The machine-learning algorithms utilize features 4606 for analyzing the data to generate an assessment 4604. The features 4606 are an individual measurable property of a phenomenon being observed. The concept of a feature is related to that of an explanatory variable used in statistical techniques such as linear regression. Choosing informative, discriminating, and independent features is important for effective operation of the MLP in pattern recognition, classification, and regression. Features may be of different types, such as numeric features, strings, and graphs. In one embodiment, the features 4606 may be of different types. For example, the features 4606 may be features of historical transaction data.
The machine-learning algorithms utilize the training data 4602 to find correlations among the identified features 4606 that affect the outcome or assessment 4604. In some embodiments, the training data 4602 includes labeled data, which is known data for one or more identified features 4606 and one or more outcomes, such as detecting fraudulent transactions.
With the training data 4602 and the identified features 4606, the machine learning tool is trained during machine-learning program training 4608. Specifically, during machine-learning program training 4608, the machine-learning tool appraises the value of the features 4606 as they correlate to the training data 4602. The result of the training is the trained machine-learning program 4610.
When the trained machine-learning program 4610 is used to perform an assessment, new data 4612 is provided as an input to the trained machine-learning program 4610, and the trained machine-learning program 4610 generates the assessment 4604 as output. For example, when transaction data is received, the historical transaction data is accessed, and the weights of the corresponding data sources are computed, the machine-learning program utilizes features of the historical transaction data to determine if the received transaction request is fraudulent or not.
In some examples, the trained machine-learning program 4610 includes a series of rules engines. Each rules engine includes a list of rules that the incoming transaction request is evaluated against before providing the assessment 4604. For example, the trained machine-learning program 4610 may include a card rules engine 4614, a payment rules engine 4616, a customer rules engine 4618, and a product rules engine 4620. The card rules engine 4614 includes a set of rules that the card data associated with transaction request must be evaluated against before providing the assessment 4604. The payment rules engine 4616 includes a set of rules that the payment data associated with the transaction request must be evaluated against before providing the assessment 4604. The customer rules engine 4618 includes a set of rules that the customer data associated with the transaction must be evaluated against before providing the assessment 4604. The product rules engine 4620 includes a set of rules that the product data must be evaluated against before providing the assessment 4604.
In some examples, payment transaction data or a fingerprint may be based on or include one or more of a merchant (tenant) ID, a patient (user) ID, or an amount of time, for example a payment transaction including these three value fields performed within a value X of a monitored time period or frequency, where X is a configurable value.
In some examples, training data for machine learning purposes is aggregated and encrypted (or anonymized) in a multitenant environment. Some fraud detection examples relate to or include data aggregation and anonymization in multi-tenant networks or networks and, in some examples, to a data aggregator and anonymizer that can encrypt sensitive data received from multiple tenants as data sources. The sensitive data may include Personally Identifiable Information (PII), Protected Health Information (PHI) and Payment Card Industry (PCI) information. In some examples, anonymized data can be aggregated for multi-faceted testing without disclosing sensitive aspects. In some examples, the aggregated data can be selectively unencrypted to a given tenant.
Results derived from an analysis of “big data” can generally be improved if the volume of test data is significant. Typically, the larger the volume of test data, the more accurate an analysis of it will be. For example, there is greater chance to identify data outliers and trends in a significant body of data. Data aggregation, however, is not easy. It may be aggregated from different sources, but each source will likely have different methods of data protection with which to comply. Each source will also very often have different data content and configuration, and this may conflict with data configuration of other sources. This aggregation of disparate sources of protected information presents technical challenges, particularly in multi-tenant networks or environments. The more data that is collected, the more complicated the security protocols become and the greater the risk of inadvertent disclosure or malicious access to it. Great care is required not to disclose encrypted information to third-party sources of aggregated data, or third-party “big data” analyzers scrutinizing collected data for discernible trends or machine-learning purposes, for example.
According to some example embodiments, techniques and systems are provided for data aggregation and anonymization in multi-tenant networks or environments. In some examples, a data aggregator and anonymizer platform can encrypt sensitive data received from multiple tenants as data sources. The sensitive data may include PII, PHI, and PCI information. In some examples, anonymized data can be aggregated for multi-faceted testing without disclosing sensitive aspects. In some examples, a portion of the aggregated data can be selectively unencrypted and returned or presented to a tenant that was the original source or keeper of that portion of the aggregated data. The remainder of the portions are not unencrypted and may continue to form part of a body of test data.
Fundamental problems that may arise when processing data in strict compliance to a regulated environment, involving PPI, PHI, or PCI for example, can occur at a confluence of healthcare and treatment information records. One challenge includes simulating a set of problems in production data using test data. For a single medical practice, for example, subscribing along with other medical practices (tenants) to a licensing and subscription service (for example) in a multi-tenant network, using a small set of test data based on its own production data may limit the body of test data that can be assembled. On the other hand, trying to build a bigger set of test data by incorporating data from other tenants accessible in the multi-tenant network runs a serious risk of privacy invasion and breach of compliance laws. Further, a desire to collect a large body of data for testing and analysis may include sourcing data that is external to the multi-tenant network and may involve the participation of third parties to analyze the data (e.g., “big data” analysis). Thus, data protection laws prevent a mere aggregation of production data for test purposes.
In other aspects, a further challenge is to simulate realistically, in test environments, what is really happening in production environments. It is difficult to obtain a representative sample of test data that actually and realistically reflects production conditions of whatever aspect the tenant may be developing (for example, an updated health service to patients, a new product offering, or an enhanced online functionality).
In further challenging aspects, production and test systems usually have layers. Lower layers can be accessed by many people, while higher layers can be accessed by relatively few. Access and security protocols differ across layers. In a regulated environment, one cannot easily bring down test information into lower layers because this may violate one or more compliance laws since wider access to this information is provided.
In order to address these and other challenges, some present examples, at a high level, classify and encrypt test information, in particular sensitive information contained in the test information, before it is brought down to lower layers. A representative sample of anonymized test data is made available for testing and, in some examples, is configurable based on data fields that might remain or are encrypted, among other factors. Once the encrypted information is brought down to lower layers, the anonymized test data may be used for a variety of testing purposes during development of a service or product, as discussed above.
Some present examples aggregate data to create a body of test data. The aggregated data may include data sourced from sources other than a single tenant (in other words, an aggregation of multi-tenant or multi-party data). For testing purposes, data analysis, or machine training purposes, an enhanced body of test data may be useful to a tenant or third-party data analyzer even though not all of the aggregated data may have been sourced from it. In this situation, a complicated cross-matrix of protection protocols such a PII, PHI, and PCI may apply, and each tenant may be entitled only to view the portion of the data that it supplied (or at least view an unencrypted version of that data). Present examples of a data aggregator and anonymizer platform facilitate the creation and access to such combined test data, yet still allow and greatly facilitate compliance with data protection laws in doing so.
In cloud-based and other modern systems (e.g., Software-as-a-Service (SaaS) platforms and so forth), most enterprises rely very heavily on third-party applications to process data. Some of these applications may include “big data” processing systems. The enterprise cannot physically control what these third parties do with their data. While inter-party agreements restricting data access and publication may be established, there is always a possibility of a rogue actor acting outside the agreed terms. A rogue actor at one tenant in a multi-tenant network might use network credentials to access another tenant to look up prohibited data. The accessed data might be used for exploitation or ransomware purposes, for example.
Thus, in some present examples, a data aggregator and anonymizer can aggregate and provide anonymized data that, even if accessed by a rogue actor, does not contain any identifying information. In some examples, a data encryption key is used to encrypt test data. In some examples, a decryption key to unlock test data is destroyed. In some examples, a decryption key to unlock a portion of aggregated test data is provided only to the tenant supplying that portion. The decryption key disallows decryption of any other data. The tenant as a source of data is thus placed in the same (unencrypted) position it was before supplying a portion of data to be aggregated, yet has enjoyed the benefit of results and analysis derived from a much larger body of test data sourced from many other, if not all, tenants in a multi-tenant network. The tenants are reassured that any contributed data that has been aggregated and shared with another tenant or third-party data analyzer has nevertheless remained encrypted for purposes such as testing, “big data” analysis, machine learning, and so forth.
With reference to
The data aggregated by the data aggregator and anonymizer 136 may be derived from a number of different data sources to assist in creating a realistic test environment or a rich body of data for analysis and training, for example. In some examples, the data may be sourced from a number of sources, without limitation. A data source may include, for example, a single tenant in a network, a plurality of tenants in a network, a single third party outside of a network, or a plurality of third parties outside of a network. Tenants or third parties may be sources of application data, web-based traffic data, or other types of data. Tenants and third parties may offer analysis tools and machine learning models, or other services.
Whether requested by a single tenant 120, or several tenants 120, the aggregated data may comprise a complicated cross-matrix of protection protocols such as PII, PHI, and PCI. Each tenant 120 may be entitled only to view a portion of the data that it supplied or, if permitted, an unencrypted version of that data.
In some examples, data sent by a tenant or accessed by the data aggregator and anonymizer 136 is encrypted at 4702 upon receipt or a grant of access. In some examples, when test data, or analyzed data results, are sent back to a tenant 120, this portion of the data is decrypted at 4704. These processes are described more fully below. The aggregated and anonymized data is stored in a database, such as the one or more databases 148 described above. Present examples of a data aggregator and anonymizer 136 facilitate the creation and access to combined test data, yet still allow and greatly facilitate compliance with data protection laws in so doing.
In some examples, one or more third-party data analyzers 114 may request access to the aggregated and anonymized data stored in the database 148 for purposes of analyzing it to support the tenant's product or service development mentioned above. A third-party data analyzer 114 may be contracted by the licensing and subscription service 106, or a tenant 120, to perform data analysis. With appropriate authorization, the third-party data analyzer 114 may be granted access to the data stored in the database 148. To the extent any access is granted, or to the extent a rogue actor may be at work, the aggregated data stored in the database 148 remains anonymized and yields no sensitive information. The data stored in the database 148 may be safely used by the third-party data analyzer 114, or a tenant 120, or the data aggregator and anonymizer 136, in a number of ways including, for example, data analysis, the development of models for machine learning, and for other purposes.
With reference to
In some examples, an AES encryption level is specific to a database persistence layer, for example as shown in
In various implementations, the operating system 4912 manages hardware resources and provides common services. The operating system 4912 includes, for example, a kernel 4924, services 4926, and drivers 4928. The kernel 4924 acts as an abstraction layer between the hardware and the other software layers, consistent with some embodiments. For example, the kernel 4924 provides memory management, processor management (e.g., scheduling), component management, networking, and security settings, among other functionality. The services 4926 can provide other common services for the other software layers. The drivers 4928 are responsible for controlling or interfacing with the underlying hardware, according to some embodiments. For instance, the drivers 4928 can include display drivers, camera drivers, BLUETOOTH® or BLUETOOTH® Low Energy drivers, flash memory drivers, serial communication drivers (e.g., Universal Serial Bus (USB) drivers), WI-FIR drivers, audio drivers, power management drivers, and so forth.
In some embodiments, the libraries 4914 provide a common low-level infrastructure utilized by the applications 4918. The libraries 4914 can include system libraries 4930 (e.g., C standard library) that can provide functions such as memory allocation functions, string manipulation functions, mathematic functions, and the like. In addition, the libraries 4914 can include API libraries 4932 such as media libraries (e.g., libraries to support presentation and manipulation of various media formats such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), graphics libraries (e.g., an OpenGL framework used to render in two dimensions (2D) and three dimensions (3D) in a graphic content on a display), database libraries (e.g., SQLite to provide various relational database functions), web libraries (e.g., WebKit to provide web browsing functionality), and the like. The libraries 4914 can also include a wide variety of other libraries 4934 to provide many other APIs to the applications 4918.
The frameworks 4916 provide a common high-level infrastructure that can be utilized by the applications 4918, according to some embodiments. For example, the frameworks 4916 provide various graphical user interface (GUI) functions, high-level resource management, high-level location services, and so forth. The frameworks 4916 can provide a broad spectrum of other APIs that can be utilized by the applications 4918, some of which may be specific to a particular operating system or platform.
In an example embodiment, the applications 4918 include a home application 4936, a contacts application 4938, a browser application 4940, a book reader application 4942, a location application 4944, a media application 4946, a messaging application 4948, a game application 4950, and a broad assortment of other applications such as a third-party application 4952. According to some embodiments, the applications 4918 are programs that execute functions defined in the programs. Various programming languages can be employed to create one or more of the applications 4918, structured in a variety of manners, such as object-oriented programming languages (e.g., Objective-C, Java, or C++) or procedural programming languages (e.g., C or assembly language). In a specific example, the third-party application 4952 (e.g., an application developed using the ANDROID™ or IOS™ software development kit (SDK) by an entity other than the vendor of the particular platform) may be mobile software running on a mobile operating system such as IOS™, ANDROID™, WINDOWS® Phone, or another mobile operating system. In this example, the third-party application 4952 can invoke the API calls 4920 provided by the operating system 4912 to facilitate functionality described herein.
The 5000 may include processors 5004, memory 5006, and I/O components 5008, which may be configured to communicate with each other such as via a bus 5010. In an example embodiment, the processors 5004 (e.g., a Central Processing Unit (CPU), a Reduced Instruction Set Computing (RISC) processor, a Complex Instruction Set Computing (CISC) processor, a Graphics Processing Unit (GPU), a Digital Signal Processor (DSP), an ASIC, a Radio-Frequency Integrated Circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 5012 and a processor 5014 that may execute the instructions 5002. The term “processor” is intended to include multi-core processors that may comprise two or more independent processors (sometimes referred to as “cores”) that may execute instructions contemporaneously. Although
The memory 5006 may include a main memory 5016, a static memory 5018, and a storage unit 5020, both accessible to the processors 5004 such as via the bus 5010. The main memory 5016, the static memory 5018, and storage unit 5020 store the instructions 5002 embodying any one or more of the methodologies or functions described herein. The instructions 5002 may also reside, completely or partially, within the main memory 5016, within the static memory 5018, within machine-readable medium 5022 within the storage unit 5020, within at least one of the processors 5004 (e.g., within the processor's cache memory), or any suitable combination thereof, during execution thereof by the machine 5000.
The I/O components 5008 may include a wide variety of components to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components 5008 that are included in a particular machine will depend on the type of machine. For example, portable machines such as mobile phones will likely include a touch input device or other such input mechanisms, while a headless server machine will likely not include such a touch input device. It will be appreciated that the I/O components 5008 may include many other components that are not shown in
In further example embodiments, the I/O components 5008 may include biometric components 5028, motion components 5030 environmental components 5032, or position components 5034, among a wide array of other components. For example, the biometric components 5028 may include components to detect expressions (e.g., hand expressions, facial expressions, vocal expressions, body gestures, or eye tracking), measure biosignals (e.g., blood pressure, heart rate, body temperature, perspiration, or brain waves), identify a person (e.g., voice identification, retinal identification, facial identification, fingerprint identification, or electroencephalogram-based identification), and the like. The motion components 5030 may include acceleration sensor components (e.g., accelerometer), gravitation sensor components, rotation sensor components (e.g., gyroscope), and so forth. The environmental components 5032 may include, for example, illumination sensor components (e.g., photometer), temperature sensor components (e.g., one or more thermometers that detect ambient temperature), humidity sensor components, pressure sensor components (e.g., barometer), acoustic sensor components (e.g., one or more microphones that detect background noise), proximity sensor components (e.g., infrared sensors that detect nearby objects), gas sensors (e.g., gas detection sensors to detection concentrations of hazardous gases for safety or to measure pollutants in the atmosphere), or other components that may provide indications, measurements, or signals corresponding to a surrounding physical environment. The position components 5034 may include location sensor components (e.g., a GPS receiver component), altitude sensor components (e.g., altimeters or barometers that detect air pressure from which altitude may be derived), orientation sensor components (e.g., magnetometers), and the like.
Communication may be implemented using a wide variety of technologies. The I/O components 5008 may include communication components 5036 operable to couple the machine 5000 to a network 5038 or devices 5040 via a coupling 5042 and a coupling 5044 respectively. For example, the communication components 5036 may include a network interface component or another suitable device to interface with the network 5038. In further examples, the communication components 5036 may include wired communication components, wireless communication components, cellular communication components, Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components to provide communication via other modalities. The devices 5040 may be another machine or any of a wide variety of peripheral devices (e.g., a peripheral device coupled via a USB).
Moreover, the communication components 5036 may detect identifiers or include components operable to detect identifiers. For example, the communication components 5036 may include Radio Frequency Identification (RFID) tag reader components, NFC smart tag detection components, optical reader components (e.g., an optical sensor to detect one-dimensional barcodes such as Universal Product Code (UPC) barcode, multi-dimensional bar codes such as Quick Response (QR) code, Aztec code, Data Matrix, Dataglyph, MaxiCode, PDF417, Ultra Code, UCC RSS-2D barcode, and other optical codes), or acoustic detection components (e.g., microphones to identify tagged audio signals). In addition, a variety of information may be derived via the communication components 5036, such as location via Internet Protocol (IP) geolocation, location via Wi-Fi® signal triangulation, location via detecting an NFC beacon signal that may indicate a particular location, and so forth.
The various memories (i.e., memory 5006, main memory 5016, static memory 5018, and/or memory of the processors 5004) and/or storage unit 5020 may store one or more sets of instructions and data structures (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. These instructions (e.g., the instructions 5002), when executed by processor 5004, cause various operations to implement the disclosed embodiments.
As used herein, the terms “machine-storage medium,” “device-storage medium,” “computer-storage medium” mean the same thing and may be used interchangeably in this disclosure. The terms refer to a single or multiple storage devices and/or media (e.g., a centralized or distributed database, and/or associated caches and servers) that store executable instructions and/or data. The terms shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media, including memory internal or external to processors. Specific examples of machine-storage media, computer-storage media and/or device-storage media include non-volatile memory, including by way of example semiconductor memory devices, e.g., erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), FPGA, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The terms “machine-storage media,” “computer-storage media,” and “device-storage media” specifically exclude carrier waves, modulated data signals, and other such media, at least some of which are covered under the term “signal medium” discussed below.
In various example embodiments, one or more portions of the network 4320 may be an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, the Internet, a portion of the Internet, a portion of the PSTN, a plain old telephone service (POTS) network, a cellular telephone network, a wireless network, a Wi-Fi® network, another type of network, or a combination of two or more such networks. For example, the network 5038 or a portion of the network 5038 may include a wireless or cellular network, and the coupling 5042 may be a Code Division Multiple Access (CDMA) connection, a Global System for Mobile communications (GSM) connection, or another type of cellular or wireless coupling. In this example, the coupling 5042 may implement any of a variety of types of data transfer technology, such as Single Carrier Radio Transmission Technology (1×RTT), Evolution-Data Optimized (EVDO) technology, General Packet Radio Service (GPRS) technology, Enhanced Data rates for GSM Evolution (EDGE) technology, third Generation Partnership Project (3GPP) including 3G, fourth generation wireless (4G) networks, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, others defined by various standard-setting organizations, other long-range protocols, or other data transfer technology.
The instructions 5002 may be transmitted or received over the network 5038 using a transmission medium via a network interface device (e.g., a network interface component included in the communication components 5036) and utilizing any one of a number of well-known transfer protocols (e.g., hypertext transfer protocol (HTTP)). Similarly, the instructions 5002 may be transmitted or received using a transmission medium via the coupling 5044 (e.g., a peer-to-peer coupling) to the devices 5040. The terms “transmission medium” and “signal medium” mean the same thing and may be used interchangeably in this disclosure. The terms “transmission medium” and “signal medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying the instructions 5002 for execution by the machine 5000, and includes digital or analog communications signals or other intangible media to facilitate communication of such software. Hence, the terms “transmission medium” and “signal medium” shall be taken to include any form of a modulated data signal, carrier wave, and so forth. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a matter as to encode information in the signal.
The terms “machine-readable medium,” “computer-readable medium” and “device-readable medium” mean the same thing and may be used interchangeably in this disclosure. The terms are defined to include both machine-storage media and transmission media. Thus, the terms include both storage devices/media and carrier waves/modulated data signals.
