U.S. patent application number 16/882279 was filed with the patent office on 2020-11-26 for system and method for providing consistent pricing information.
This patent application is currently assigned to Capital One Services, LLC. The applicant listed for this patent is Capital One Services, LLC. Invention is credited to Pedro BETANCOURT, Satish KESIBOYANA, Suresh PANDEY.
Application Number | 20200372531 16/882279 |
Document ID | / |
Family ID | 1000004898062 |
Filed Date | 2020-11-26 |
United States Patent
Application |
20200372531 |
Kind Code |
A1 |
KESIBOYANA; Satish ; et
al. |
November 26, 2020 |
SYSTEM AND METHOD FOR PROVIDING CONSISTENT PRICING INFORMATION
Abstract
In an embodiment, the system provides consistent pricing
structures of a loan irrespective of the type of application
requesting the pricing structure. The system generates a
prequalification result for a product and user, in response to
processing an initial prequalification request received from a
given application. The system uses the prequalification result to
generate a pricing structure. The prequalification result and
pricing structure are stored. The system receives a subsequent
purchase request for the product and user, from a different type of
application. The system retrieves the prequalification result and
pricing structure to generate a second pricing structure including
the same pricing information as the previously generated pricing
structure for the product and user. This ensures the customer is
provided consistent pricing for a loan across platforms.
Inventors: |
KESIBOYANA; Satish; (Plano,
TX) ; BETANCOURT; Pedro; (Mckinney, TX) ;
PANDEY; Suresh; (Mckinney, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Capital One Services, LLC |
McLean |
VA |
US |
|
|
Assignee: |
Capital One Services, LLC
McLean
VA
|
Family ID: |
1000004898062 |
Appl. No.: |
16/882279 |
Filed: |
May 22, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62852202 |
May 23, 2019 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 16/9562 20190101;
G06Q 40/025 20130101; G06Q 30/0206 20130101 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02; G06Q 40/02 20060101 G06Q040/02; G06F 16/955 20060101
G06F016/955 |
Claims
1. A method for providing consistent pricing information, the
method comprising: generating, by one or more computing devices, a
prequalification result in response to an initial prequalification
request for a user; storing, by the one or more computing devices,
the prequalification result in an applications database;
generating, by the one or more computing devices, a pricing
structure for a specified product for the user, based on the
prequalification result; storing, by the one more computing
devices, the pricing structure for the specified product for the
user, in a pricing database, for a predetermined time frame, using
a bookmarking micro-service; receiving, by the one or more
computing devices, a pricing request for the specified product for
the user, the pricing request including user information; querying,
by the one or more computing devices, the applications database,
using a customer micro-service, to determine whether a
prequalification result for the user exists, based on the user
information; in response to determining the prequalification result
for the user exists, querying, by the one or more computing
devices, the pricing database, using the bookmark micro-service, to
determine whether a pricing structure for the specified product has
been generated for the user in the predetermined time frame; and in
response to determining a pricing structure for the specified
product has been generated for the user in the predetermined time
frame, transmitting, by the one or more computing devices, the
pricing structure for the specified product.
2. The method of claim 1, further comprising identifying, by the
one or more computing devices, the pricing structure in the pricing
database based on a prequalification identifier of the
prequalification result and a user identifier of the user.
3. The method of claim 1, further comprising: identifying, by the
one or more computing devices, a type of application transmitting
the initial prequalification request; identifying, by the one or
more computing devices, a set of rules tied to the type of
application transmitting the initial prequalification request; and
processing, by the one or more computing devices, the
prequalification request based on the set of rules to generate the
prequalification result.
4. The method of claim 1, wherein the pricing structure includes
product information, user information, and lender information.
5. The method of claim 1, further comprising: receiving, by the one
or more computing devices, a second pricing request of the
specified product for the user; and generating, by the one or more
computing devices, a second pricing structure for the specified
product.
6. The method of claim 1, further comprising receiving, by the one
or more computing devices, an initial pricing request for the
specified product.
7. The method of claim 1, wherein receiving the initial pricing
request from an application of a first type executing on a user
device and receiving the pricing request from an application of a
second type executing on a seller device.
8. A system for providing consistent pricing information, the
system comprising: a memory; a processor copulated to the memory,
the processor configured to: generate a prequalification result in
response to an initial prequalification request for a user; store
the prequalification result in an applications database; generate a
pricing structure for a specified product for the user, based on
the prequalification result; store the pricing structure for the
specified product for the user, in a pricing database, for a
predetermined time frame, using a bookmarking micro-service;
receive a pricing request for the specified product for the user,
the pricing request including user information; query the
applications database, using a customer micro-service, to determine
whether a prequalification result for the user exists, based on the
user information; in response to determining the prequalification
result for the user exists, query the pricing database, using the
bookmark micro-service, to determine whether a pricing structure
for the specified product has been generated for the user in the
predetermined time frame; and in response to determining a pricing
structure for the specified product has been generated for the user
in the predetermined time frame, transmit the pricing structure for
the specified product.
9. The system of claim 8, wherein the processor is further
configured to: identify the pricing structure in the pricing
database based on a prequalification identifier of the
prequalification result and a user identifier of the user.
10. The system of claim 8, the processor is further configured to:
identify a type of application transmitting the initial
prequalification request; identify a set of rules tied to the type
of application transmitting the initial prequalification request;
and process the prequalification request based on the set of rules
to generate the prequalification result.
11. The system of claim 8, wherein the pricing structure includes
product information, user information, and lender information.
12. The system of claim 8, wherein the processor is further
configured to: receive a second pricing request of the specified
product for the user; and generate a second pricing structure for
the specified product.
13. The system of claim 8, wherein the processor is further
configured to: receive an initial pricing request for the specified
product.
14. The system of claim 8, the processor is further configured to:
receive the initial pricing request from an application of a first
type executing on a user device and receiving the pricing request
from an application of a second type executing on a seller
device.
15. A non-transitory computer-readable medium storing instructions
that when executed by one or more processors of a device cause the
one or more processors to perform operations comprising: generating
a prequalification result in response to an initial
prequalification request for a user; storing the prequalification
result in an applications database; generating a pricing structure
for a specified product for the user, based on the prequalification
result; storing the pricing structure for the specified product for
the user, in a pricing database, for a predetermined time frame,
using a bookmarking micro-service; receiving a pricing request for
the specified product for the user, the pricing request including
user information; querying the applications database, using a
customer micro-service, to determine whether a prequalification
result for the user exists, based on the user information; in
response to determining the prequalification result for the user
exists, querying the pricing database, using the bookmark
micro-service, to determine whether a pricing structure for the
specified product has been generated for the user in the
predetermined time frame; and in response to determining a pricing
structure for the specified product has been generated for the user
in the predetermined time frame, transmitting the pricing structure
for the specified product
16. The non-transitory computer-readable medium of claim 15,
wherein the instructions when executed cause the one or more
processors to: identify, by the one or more computing devices, the
pricing structure in the pricing database based on a
prequalification identifier of the prequalification result and a
user identifier of the user.
17. The non-transitory computer-readable medium of claim 15,
wherein the instructions when executed cause the one or more
processors to: identify, by the one or more computing devices, a
type of application transmitting the initial prequalification
request; identify, by the one or more computing devices, a set of
rules tied to the type of application transmitting the initial
prequalification request; and process, by the one or more computing
devices, the prequalification request based on the set of rules to
generate the prequalification result.
18. The non-transitory computer-readable medium of claim 15,
wherein the pricing structure includes product information, user
information, and lender information.
19. The non-transitory computer-readable medium of claim 15,
wherein the instructions when executed cause the one or more
processors to: receive, by the one or more computing devices, a
second pricing request of the specified product for the user; and
generate, by the one or more computing devices, a second pricing
structure for the specified product
20. The non-transitory computer-readable medium of claim 15,
wherein the instructions when executed cause the one or more
processors to: receive, by the one or more computing devices, an
initial pricing request for the specified product.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of Provisional
Application No. 62/852,202, filed on May 23, 2019, the contents of
which are hereby incorporated by reference in their entirety.
BACKGROUND
[0002] Conventionally, when applying for a loan for financing a
vehicle purchase, for example, a user may use online tools to
interact with prospective lenders to understand their purchasing
power before or during a vehicle search. The user may also interact
with the lender again at a later time or through a different
channel as part of the vehicle purchase process, for example.
Lenders may apply different methodologies for generating pricing
structures depending on a timing of a loan inquiry or the channel
through which the inquiry is received. This may lead to a user
receiving different pricing structures for a loan depending on when
and how they interact with the lender, which may cause inconsistent
results and uncertainty and may cause the user to attempt to
reprocess their loan application. By doing so, the conventional
systems may have to re-process the same information multiple times,
causing operational inefficiencies and re-execution of
computationally expensive operations.
BRIEF DESCRIPTION OF THE DRAWINGS
[0003] The accompanying drawings, which are incorporated herein and
form a part of the specification, illustrate the embodiments of the
present disclosure, and together with the description, further
serve to explain the principles of the embodiments and enable a
person skilled in the pertinent art to make and use the
embodiments, individually, or as a combination thereof.
[0004] FIG. 1 is a block diagram of an example network environment
according to an exemplary embodiment.
[0005] FIG. 2 is a block diagram of an example architecture
according to an embodiment.
[0006] FIG. 3 is a block diagram illustrating an expanded view of
example micro-services in accordance to an embodiment.
[0007] FIG. 4 is a flowchart illustrating the process of obtaining
consistent pricing information in accordance to an example
embodiment.
[0008] FIG. 5 is a flowchart illustrating the process of obtaining
consistent pricing information in accordance to an example
embodiment.
[0009] FIG. 6 is a block diagram of example components of a
computing system according to an embodiment.
[0010] In the drawings, like reference numbers generally indicate
identical or similar elements. Additionally, generally, the
left-most digit(s) of a reference number identifies the drawing in
which the reference number first appears.
DETAILED DESCRIPTION
[0011] Provided herein are system, apparatus, device, method and/or
computer program product embodiments, and/or combinations and
sub-combinations thereof for providing consistent pricing
information across different channels or platforms or within a
duration of time.
[0012] A user may intend to purchase a product from a seller, which
may require acquiring a loan. The user may submit an initial
prequalification request, for getting prequalified for a loan for
purchasing a product, using a user device. The system may receive
the initial prequalification request. The system may identify that
the user transmitted the prequalification request from a first
channel, e.g., an application executing on the user device. The
system may retrieve rules for processing the prequalification
request for various lenders. The rules may be specifically directed
to processing a prequalification request for users submitting the
prequalification requests from the particular channel, e.g., the
application executing on the user device. The system may generate a
prequalification result in response to processing the
prequalification request based on the retrieved rules for the
lenders. The prequalification result may be transmitted to the user
device and saved in an applications database.
[0013] The user may submit a pricing request for pricing a loan for
purchasing a specified product from the user device. The system may
retrieve the prequalification result from the applications database
and generate a pricing structure for using the prequalification
result. The pricing structure may be transmitted to the user device
and saved in a pricing database.
[0014] The user may again interact with one or more of the various
lenders (directly or indirectly) as part of the purchase process
through a different channel (e.g., a channel associated with a
seller of the product). For example, the seller may input the user
information and information of the specified product in a seller
device and submit a purchase request for the specified product to
one or more of the lenders or a platform associated with the
lenders. The system may query the applications database to
determine whether a prequalification result for the user exists,
based on the user information. In response to determining the
prequalification request for the user exists, the system may query
the pricing database to determine whether a pricing structure for
the specified product has been generated for the user in a
predetermined time frame. In response to determining a pricing
structure for the specified product that has been generated for the
user in the predetermined time frame, the system may generate and
transmit a second pricing structure for the specified product using
the earlier generated pricing structure. The second pricing
structure may include the same pricing information as the pricing
structure previously generated for the specified product and
user.
[0015] The system may provide consistent pricing structures of a
loan irrespective of a channel through which a user directly or
indirectly is requesting decisioning (e.g. pricing or pricing
structure) for an application for financing purchase of a product.
The system may generate a new pricing structure based on a
previously generated pricing structure for the customer. This
ensures the customer is provided consistent pricing for a loan
across different channels and platforms. Furthermore, by providing
consistent pricing, the system does not re-process the same data
repeatedly and thusly, saves computational resources.
[0016] FIG. 1 is a block diagram of an example environment in which
systems and/or methods described herein may be implemented. The
environment may include a central system 100, a seller device 114,
a backend platform 125, a cloud computing environment 132, a user
device 140, a pricing database 148, an applications database 146,
and a network 130. The devices of the environment may be connected
through wired connections, wireless connections, or a combination
of wired and wireless connections.
[0017] In an example embodiment, one or more portions of the
network 130 may be an ad hoc network, an intranet, an extranet, a
virtual private network (VPN), a local area network (LAN), a
wireless LAN (WLAN), a wide area network (WAN), a wireless wide
area network (WWAN), a metropolitan area network (MAN), a portion
of the Internet, a portion of the Public Switched Telephone Network
(PSTN), a cellular telephone network, a wireless network, a WiFi
network, a WiMax network, any other type of network, or a
combination of two or more such networks.
[0018] The backend platform 125 may include one or more devices
configured to host a multi-lender architecture (e.g., architecture
as shown in FIGS. 1-2). The backend platform 125 may include a
server or a group of servers. In an embodiment, the backend
platform 125 may be hosted in a cloud computing environment 132. It
may be appreciated that the backend platform 125 may not be
cloud-based, or may be partially cloud-based.
[0019] The central system 100, seller device 114, user device 140,
pricing database 148, and applications database 146 may include one
or more devices configured to interface with the backend platform
125. The central system 100 may include a pre-qualification
micro-service 102, eligibility micro-service 104, pricing
micro-service 106, customers micro-service 110, and bookmark
micro-service 112. The user device 140 may include a display 142, a
first buyer application 144, and a second buyer application 145.
The first buyer application 144 can be a channel associated with a
lender. The second buyer application 145 can be a channel
associated with a seller. The seller device 114 may include a
seller application 118 and a display 120. The first buyer
application 144, second buyer application 145, and seller
application 118 may interface with the central system 100 to obtain
loan offers for products that are intended to be purchased.
[0020] In an embodiment, the prequalification micro-service 102 may
process, in parallel, the user's pre-qualification request with one
or more different lenders using the user's personal information and
the pre-qualification decisioning information associated with each
respective lender. The pre-qualification decisioning information
may be different for each lender. For example, each lender may
require different thresholds of employment information, salary,
and/or credit scores.
[0021] In an embodiment, the eligibility micro-service 104 may
generate product eligibility results. The product eligibility
results may determine whether a product is eligible for financing
for a given lender and user.
[0022] In an embodiment, the pricing micro-service 106 may generate
pricing offers for loans for a given product based on the
pre-qualification and product eligibility results. For example, the
prequalification micro-service 102 can receive a prequalification
request from the seller application 118. The prequalification
micro-service 102 may retrieve methodologies for processing the
prequalification request for various lenders. The prequalification
micro-service 102 may process, in parallel, the user's
pre-qualification request, using a user's personal information,
credit information, and methodologies associated with each
respective lender. The prequalification micro-service 102 may
generate prequalification results including decisions of
prequalification of the loan from various lenders and loan details
offered by each of the lenders, based on the user's personal
information, soft pull, and methodologies specific to each
lender.
[0023] The pricing micro-service 108 can receive a pricing request
from a different channel (e.g., first or second buyer application
144 or 145) as compared to the channel used to transmit the
prequalification request. The pricing micro-service 108 may
generate a pricing structure irrespective of the type of channel
that transmitted the pricing request, given that the pricing
request is received within a specified timeframe of the
prequalification result.
[0024] In an embodiment, the prequalification micro-service 102 may
retrieve prequalification information for a lender. The lender's
prequalification information may include prequalification rules,
methodologies, or algorithms, on how to process prequalification
requests. The prequalification micro-service 102 may generate a
prequalification result for the user using the user's information,
the received credit information, information about the specific
product, information about the third-party, and the
prequalification information for the lender. For example,
prequalification micro-service 102 may call on the eligibility
micro-service 104 to determine whether the product is eligible for
a loan from the lender. The eligibility micro-service 104 can use
the lender's prequalification information and product information
to determine whether the product is eligible for a loan. Once the
eligibility micro-service 104 confirms that the product is eligible
for a loan from the lender, the prequalification micro-service 102
can generate the prequalification result using the user's
information, the received credit information, information about the
specific product, information about the third-party, and the
prequalification information for the lender. The prequalification
micro-service 102 can call the pricing micro-service 108 to
determine an APR and pricing information. The prequalification
result can include a specific APR and pricing information for the
specific user and product. This can be an actionable
prequalification result. That is, the user can select this
prequalification result to obtain a final loan-pricing structure
that includes the same APR and pricing information for the specific
user and product as in the prequalification result.
[0025] In an embodiment, applications database 146 can store
pre-qualification information for users. The pre-qualification
information may include decisions on loan requests from various
lenders. The pricing database 148 may store information about loan
offers for products based on financing information and information
about the product.
[0026] The cloud computing environment 132 includes an environment
that delivers computing as a service, whereby shared resources,
services, etc. may be provided to the device 100 and/or the backend
platform 125. The cloud computing environment 132 may provide
computation, software, data access, storage, and/or other services
that do not require end-user knowledge of a physical location and
configuration of a system and/or a device that delivers the
services. The cloud computing system 132 may include computing
resources 126a-d.
[0027] Each computing resource 126a-d includes one or more personal
computers, workstations, computers, server devices, or other types
of computation and/or communication devices. The computing
resource(s) 126a-d may host the backend platform 125. The cloud
resources may include compute instances executing in the computing
resources 126a-d. The computing resources 126a-d may communicate
with other computing resources 126a-d via wired connections,
wireless connections, or a combination of wired or wireless
connections.
[0028] Computing resources 126a-d may include a group of cloud
resources, such as one or more applications ("APPs") 126-1, one or
more virtual machines ("VMs") 126-2, virtualized storage ("VS")
126-3, and one or more hypervisors ("HYPs") 126-4.
[0029] Application 126-1 may include one or more software
applications that may be provided to or accessed by the user device
140, seller device 114 and the lender device 1103. In an
embodiment, the application 1104 may execute locally on the user
device 140, seller device 114 and the lender device 1103.
Alternatively, the application 126-1 may eliminate a need to
install and execute software applications on the user device 140,
seller device 114 and the lender device 1103. The application 126-1
may include software associated with backend platform 125 and/or
any other software configured to be provided across the cloud
computing environment 132. The application 126-1 may send/receive
information from one or more other applications 126-1, via the
virtual machine 126-2.
[0030] Virtual machine 126-2 may include a software implementation
of a machine (e.g., a computer) that executes programs like a
physical machine. Virtual machine 126-2 may be either a system
virtual machine or a process virtual machine, depending upon the
use and degree of correspondence to any real machine by virtual
machine 126-2. A system virtual machine may provide a complete
system platform that supports execution of a complete operating
system (OS). A process virtual machine may execute a single program
and may support a single process. The virtual machine 126-2 may
execute on behalf of a user (e.g., the user device 140, seller
device 114) and/or on behalf of one or more other backend platforms
125, and may manage the infrastructure of the cloud computing
environment 132, such as data management, synchronization, or
long-duration data transfers.
[0031] Virtualized storage 126-3 may include one or more storage
systems and/or one or more devices that use virtualization
techniques within the storage systems or devices of computing
resource 126a-d. With respect to a storage system, types of
virtualizations may include block virtualization and file
virtualization. Block virtualization may refer to abstraction (or
separation) of logical storage from physical storage so that the
storage system may be accessed without regard to physical storage
or heterogeneous structure. The separation may permit
administrators of the storage system flexibility in how
administrators manage storage for end users. File virtualization
may eliminate dependencies between data accessed at a file-level
and location where files are physically stored. This may enable
optimization of storage use, server consolidation, and/or
performance of non-disruptive file migrations.
[0032] Hypervisor 126-4 may provide hardware virtualization
techniques that allow multiple operations systems (e.g., "guest
operating systems") to execute concurrently on a host computer,
such as computing resource 126a-d. Hypervisor 126-4 may present a
virtual operating platform to the guest operating systems and may
manage the execution of the guest operating systems multiple
instances of a variety of operating systems and may share
virtualized hardware resources.
[0033] In an embodiment, a user of a user device may desire to
request pre-qualification for a loan for purchasing a product from
a lender or one or more of multiple lenders using the first or
second buyer applications 144, 145. In response to launching the
first buyer application 144 or second buyer application 145 (e.g.,
lender or seller channel), the user may be prompted to input user
information for transmitting a prequalification request. The first
buyer application 144 or second buyer application 145 may receive
input from a user for requesting prequalification for a loan for
purchasing a product. The input may be user information needed to
process the prequalification request. For example, the user
information may include, full name, address, social security
number, employment information, salary, and/or the like. The user
device 140 may transmit the prequalification request including
received user information, to the central system 100.
[0034] The central system 100 may receive the prequalification
request including the user information. The central system 100 may
transmit the user information to the prequalification micro-service
102. The prequalification micro-service 102 may identify the
application transmitting the prequalification request or the
channel from which the prequalification request is initiated (e.g.,
first or second buyer application 144, 145). Initially, the
prequalification micro-service 102 may interface with third-party
credit bureau's to execute a soft pull for the user to determine
the user's credit score, using the user's personal information.
Soft pulls are soft credit inquires that do not affect the user's
credit score. The prequalification micro-service 102 may retrieve
methodologies (e.g. decisioning logic) used by the lenders to
process prequalification. Each lender may have different
methodologies for processing the prequalification for the user.
Furthermore, each lender may have different methodologies for
processing the prequalification for the user, based on the
identified application transmitting the prequalification request or
the channel from which the prequalification request is initiated.
For example, the prequalification micro-service 102 may identify
that a buyer application has transmitted the prequalification
request. The prequalification micro-service 102 may retrieve
methodologies for processing prequalification requests received
from buyer applications, for each lender. The prequalification
micro-service 102 may process, in parallel, the user's
pre-qualification request, using the user's personal information,
soft pull and retrieved methodologies associated with each
respective lender. The prequalification micro-service 102 can call
the pricing micro-service 108 to generate the Annual Percentage
Rate (APR) using the user's personal information, soft pull and
retrieved methodologies associated with each respective lender. The
prequalification micro-service 102 may generate prequalification
results including decisions of prequalification of the loan from
various lenders and loan details offered by each of the lenders,
based on the user's personal information, soft pull, and
methodologies specific to each lender. For example, the loan
details may include the APR.
[0035] The central system 100 may route the prequalification
results to the user device 140. In an embodiment, the central
system 100 may transmit the prequalification results to the user
device 140 be rendered on the first or second buyer applications
144, 145. The customers micro-service 110 may also store the
prequalification results in the applications database 146. The
customers micro-service 110 may maintain an association between the
user and the prequalification results, in the applications database
146. The prequalification results may have a prequalification
identifier and the user may have a user identifier. The user
identifier may be correlated to each prequalification result
identifier.
[0036] The first or second buyer application 144, 145 may transmit
a pricing request to the central application 100 to generate a
pricing structure for a specified product. The eligibility
micro-service 104 may determine whether the specified product is
eligible for a loan. The customers micro-service 110 may query the
applications database 146 to determine whether prequalification
results existed for the user that had been processed within a
specified time frame. The customers micro-service 110 may retrieve
the prequalification results for the user from the applications
database 146. The pricing micro-service 108 may interface with
third-party credit bureaus to execute a hard credit pull on the
user. In the event, prequalification results exist for the user,
the pricing micro-service 108 may verify the loan details provided
to the user in the prequalification result based on the hard pull.
In response to verifying the loan details, the pricing
micro-service 108 can generate a pricing structure based on a
prequalification result. The pricing structure can include the same
loan details as the prequalification result.
[0037] In the event, a prequalification result does not exist for a
user, the pricing micro-service 108 is unable to verify the loan
details based on the hard pull, or a user changes their purchasing
structure, the pricing micro-service 108 can generate a new pricing
structure. The pricing micro-service 108 may retrieve the lenders'
methodologies for generating a pricing structure. The pricing
micro-service 108 may generate a pricing structure for a loan for
the specified product, based on the prequalification results,
specified product details, the lenders' methodologies, and the hard
credit pull. The respective pricing structure generated for the
user for each lender may be the same as provided during the
prequalification process regardless of the application or channel
transmitting the pricing request if the prequalification results
are generated for the same user within a given time frame. The
pricing structure may include the loan details for the specified
product. For example, the pricing structure may include, APR,
payment schedule, terms and condition of the loan, type of loan,
and/or the type.
[0038] The central system 100 may route the pricing structure to
the user device 140. In an embodiment, the central system 100 may
transmit the pricing structure to the user device 140 be rendered
on the first or second buyer application 144, 145. The user may
select to bookmark the pricing structure. In response to the user
selecting to bookmark the pricing structure, the bookmark request
may be transmitted to the central system 100. The bookmark
micro-service 112 may store the pricing structure and correlate the
pricing structure to the user in the pricing database.
[0039] The user may subsequently interact with a seller of the
specified product to purchase the product. The seller of the
specified product may launch the seller application 118 on the
seller device 114 to initiate a pricing request for the specified
product for the user. The seller may input information about the
user on the seller application 118 and the specified product. The
seller application 118 may transmit a pricing request for specified
product and user to the central system 100.
[0040] The customers micro-service 110 may query the applications
database 146 using the user information, to retrieve any
prequalification results for the user. The customers micro-service
may forward the user identifier received from the prequalification
results to the bookmark micro-service 112. The bookmark
micro-service 112 may query the pricing database 148 to determine
whether the specified product had been priced for the user at a
previous point in time, within a specified timeframe, using the
user identifier. In response to determining the specified product
had been priced for the user at a previous point in time, within a
specified timeframe, the bookmark micro-service may retrieve the
previously generated pricing structure. The pricing micro-service
108 provide the previously generated pricing structure to the
user.
[0041] It can be appreciated that the initial prequalification or
pricing request may be generated using the seller application 118
and subsequent pricing request may be generated using the first or
second buyer applications 144, 145 (or vice versa). The lenders'
methodologies applied to generate the prequalification results may
be dependent on the type of the application transmitting the
initial prequalification request. For example, the lenders'
methodologies may be different when transmitting a prequalification
request from the seller application 118, the first buyer
application 144, or second buyer application 145. The different
methodologies can affect the pricing structures.
[0042] As stated above, after transmitting the initial
prequalification result, the pricing micro-service 108 may receive
a pricing request from the first or second buyer applications 144
or 145. The pricing micro-service 108 may generate the pricing
structures based on the prequalification request, irrespective of
the type of application transmitting the pricing request (e.g., the
first and second buyer application 144 and 145), given that the
pricing request is received within a specified timeframe of the
prequalification result.
[0043] As a non-limiting example, the seller may be an automobile
dealership, the products may be automobiles and the type of loan
may be auto-financing.
[0044] FIG. 2 is block diagrams illustrating an architecture
implementing the system described herein, according to an
embodiment. The architecture may include a buyer UI 200, a seller
UI 202, a Digital Retailer 204, Buy/Sell API 210, and a
multi-lender layer 212. The buyer UI 200 may correspond with the
first and second buyer application. The seller UI 202 may
correspond with the seller application. The Buy/Sell API 210 may
reside in an experience layer 208. The Buy/Sell API 210 may
facilitate communication between the buyer UI 200, seller UI 202,
and/or Digital Retailer 103 and the multi-lender layer 212. The
architecture may further include a lender portal 220 through which
lenders may access the multi-lender layer.
[0045] The multi-lender layer 212 may include an API Passthru 214
and a vault 216. The vault 216 may reside in the central system.
The API Passthru 214 may be an API Gateway. The API Passthru 214
may be responsible for request routing, composition, and protocol
translation. The lender portal 220 may also reside in the
multi-lender layer 212. The vault 216 may include micro-processes
such as prequalification 102, product eligibility 104, and pricing
10. The vault 216 may also include an encrypted logs 222 and a
lender confidential repository 221. The encrypted logs 222 may be a
data repository.
[0046] In an embodiment, a plurality of lenders 226 may interface
with the lender portal 220 to upload and/or communicate information
(e.g., methodologies) associated with their prequalification,
product eligibility, and pricing, to the vault 216. The information
may include rules, algorithms, equations, restrictions, and/or the
like, which govern the process of offering users loans for products
at determined prices. The information may be stored in the lender
confidential repository 221. In an embodiment, the information
received and stored in an encrypted format. Alternatively, the
information may be received in an encrypted format. The vault 216
may decrypt the information using the encryption service 218 and
store the information in a decrypted format.
[0047] In an embodiment, the prequalification micro-service 102 may
retrieve prequalification information for a lender. The lender's
prequalification information may include prequalification rules,
methodologies, or algorithms, on how to process prequalification
requests. The prequalification micro-service 102 may generate a
prequalification result for the user using the user's information,
the received credit information, information about the specific
product, information about the third-party, and the
prequalification information for the lender. For example,
prequalification micro-service 102 may call on the eligibility
micro-service 104 to determine whether the product is eligible for
a loan from the lender. The eligibility micro-service 104 can use
the lender's prequalification information and product information
to determine whether the product is eligible for a loan. Once the
eligibility micro-service 104 confirms that the product is eligible
for a loan from the lender, the prequalification micro-service 102
can generate the prequalification result using the user's
information, the received credit information, information about the
specific product, information about the third-party, and the
prequalification information for the lender. The prequalification
micro-service 102 can call the pricing micro-service 108 to
determine an APR and pricing information. The prequalification
result can include a specific APR and pricing information for the
specific user and product. This can be an actionable
prequalification result. That is, the user can select this
prequalification result to obtain a final loan-pricing structure
that includes the same APR and pricing information for the specific
user and product as in the prequalification result.
[0048] As lenders 226 may upload proprietary information (e.g.
decisioning and pricing logic) into the vault 216, the vault 216
may provide a secure environment in which the proprietary
information may not be visible to anyone else (including the
administrator of the multi-lender architecture) other than the
lender. The vault 216 may reside in a jailed, self-contained
network, configured to receive and transmit data in an encrypted
format. In this self-contained network, lenders may manage their
separate accounts. Each lender can securely manage its loan
eligibility criteria, rules, filing policies, and/or the like.
Lenders 226 may view their data inside the vault 216 and may not
view data associated with other lenders 226. The data inside the
vault 216 may not be visible to users through the buyer UI, seller
UI 202, or Digital retailer 204.
[0049] In an embodiment, buyer UI 200 may correspond an application
configured to search for products and procure pricing structure for
a loan from various lenders, executing on a customer's device.
Seller UI 202 may be an application configured for searching for
products and procuring pricing structure for a loan from various
lenders, executing on a seller's device. Digital retailer 204 can
be a website or online application configured to sell products and
allow users to interface with a lender to obtain a loan for a
product sold on the website. The loan can be one or more of: an
automobile loan, a mortgage, unsecured personal loans, secured
personal loans, debt consolidation loans, or variable-interest
loans. The product for sale can be a house, car, motorcycle,
recreational vehicle (RV), aircraft, boat, and/or the like.
[0050] As an example, a user may interface with buyer UI 200,
seller application 118, or digital retailer 204 in an attempt to
obtain a pricing structure for a loan for a product. In one
embodiment, the buyer UI 200, seller UI 202, or digital retailer
204 may each render different graphical user interfaces (GUIs)
configured to receive input from the user which may be transmitted
to the multi-lender layer for further processing, to obtain pricing
structure for a loan for a product. The input information may be
transmitted to the multi-lender layer 212 through the Buy/Sell API
210. Information may be communicated from the multi-lender layer
212 to buyer UI 200, seller UI 202, or Digital retailer 204 through
the Buy/Sell API 210, to be rendered in the respective GUI.
[0051] In one embodiment, a digital retailer 204 (i.e., a
third-party system) may be embodied as a web domain associated with
the seller. Digital retailer 204 may render a hyperlink. The
Digital retailer 204 may interface with the multi-lender layer 212
using the hyperlink.
[0052] In an embodiment, the seller UI 202 may interface with the
multi-lender layer 212 to determine prequalification, product
eligibility, and pricing as described with respect to buyer UI 200.
The seller UI 202 may transmit a link directed to the multi-layer
lender to initiate a prequalification request to a user device. As
an example, the seller UI 202 may transmit the link via Short
Messaging Service (SMS) or e-mail message to the user device. The
user may transmit a prequalification request using the link as
described above.
[0053] The prequalification micro-service 102 may receive a
prequalification request from the seller UI 202 for a user and a
specified product. The prequalification micro-service 102 may
generate a prequalification result as described above. The
prequalification result may include loan details for the user and
product.
[0054] Subsequently, the pricing micro-service 108 may receive a
pricing request from the buyer UI 200 for the same user and
product. The pricing micro-service can use the generated
prequalification result to generate a pricing structure, given that
the pricing request was transmitted within a specified timeframe of
the prequalification request. The pricing structure can include the
same loan details as the prequalification result.
[0055] The vault 216 may process the prequalification, product
eligibility, and pricing structure associated with building a loan
offer for multiple lenders, in parallel, using proprietary
information provided by each lender. As described above, the vault
216 may be a jailed environment, such that, while the lenders 226
may provide their proprietary information for building a loan offer
to be stored in the vault 216, the lenders or users may not access
or view other lenders' proprietary information for building a loan
offer. This configuration provides a technical advantage over
conventional systems because this configuration can generate
multiple loan offers from various lenders in parallel using each
lender's proprietary information while maintaining a secure jailed
environment restricting access or visibility to the lenders'
proprietary information.
[0056] As an example, the user may interface with the buyer UI 200
to obtain a pricing structure for a loan for a product. The buyer
UI 200 may present a selection for requesting to getting
prequalified. In response to the user selecting the request for
getting pre-qualified, the buyer UI 200 may receive input
associated with personal information of the user (e.g., name,
address, asset information, salary, employment information, social
security number, and/or the like). In one embodiment, the buyer UI
200 transmits the encrypted personal information and
prequalification request to the multi-lender layer 212, via the
Buy/Sell API 210, using Hypertext Transfer Protocol Secure (HTTPS).
In an embodiment, the buyer UI 200 may encrypt the personal
information and prequalification request and transmit the encrypted
personal information and prequalification request to the
multi-lender layer 212, via the Buy/Sell API 210. In another
embodiment, portions of the personal information may be encrypted
by the buyer UI 200, such as the social security number (SSN).
[0057] The Buy/Sell API 210 can determine which lenders can provide
loans for products based on personal information. For example, the
Buy/Sell API 210 may determine a set of lenders can provide loans
for products based on the personal information provided by the
user. The Buy/Sell API 210 can generate a prequalification request
for each lender in the set of lenders and transmit each request to
the multi-lender layer 212.
[0058] The API Passthru 214 may receive the encrypted input from
the Buy/Sell API 210, in the multi-lender layer 212. The API
Passthru 214 may forward the personal information along with the
prequalification requests for each lender of the set of lenders to
the vault 216. The vault 216 may execute the prequalification
micro-service 102. The prequalification micro-service 102 may
interface with third party credit bureaus to retrieve user credit
information using the decrypted personal information associated
with the user. The prequalification micro-service 102 may request
the third party credit bureaus to initiate a soft pull. The
prequalification micro-service 102 may retrieve prequalification
information associated with each of the set of lenders from the
lender confidential repository 221. The prequalification
micro-service 102 may retrieve information associated with each of
the set of lenders for processing a prequalification result, based
on the type of application (e.g., buyer application) transmitting
the request. Lenders may process prequalification differently
depending on the channel from which a request is received, e.g.
whether the request is received through the buyer UI 200 or through
the seller UI 202 may be a factor that effects a decisioning or
pricing determination. For example, some lenders may offer special
deals to sellers for generating loans for their buyers.
Alternatively, some lenders may offer promotions to buyers for
applying for loans on their own using the buyer UI 200. The lender
proprietary information may include rules on how each lender
processes prequalification.
[0059] The prequalification micro-service 102 may process, in
parallel, the user's prequalification request for each of the set
of lenders using the user's personal information and the
prequalification information associated with each respective
lender. As described above, the prequalification may be different
for each lender. For example, each lender may require different
thresholds of employment information, salary, and/or credit
scores.
[0060] The prequalification micro-service 102 may generate
prequalification results, in response to processing the user's
prequalification request for each of the multiple lenders. The
prequalification results may include a subset of lenders from the
set of lenders which have pre-qualified the user for a loan for a
product based on the personal information of the user, and the and
the prequalification information associated with the respective
lender. The prequalification results can include a decision on
whether the lender has pre-qualified a user for a loan for a
product. In an embodiment, the prequalification results may also
include information associated with the loan such as a range of
possible Annual Percentage Rates (APRs) and terms and conditions of
the loans. In an embodiment, the vault 216 may transmit the
prequalification results to the buyer UI 200 unencrypted.
Alternatively, the vault 216 may encrypt the prequalification
results using the encryption service 218 and transmit the encrypted
prequalification results to the API Passthru 214. The API Passthru
214 may forward the prequalification results to the Buy/Sell API
210. The Buy/Sell API 210 may transmit the prequalification results
to the buyer UI 200. In the event the prequalification results are
encrypted, the buyer UI 200 can decrypt the encrypted
prequalification results. The buyer UI 200 can render the
prequalification results on the buyer UI's GUI.
[0061] Continuing from the earlier example, after the
prequalification results being rendered on the GUI of the buyer UI
200, the buyer UI 200 may receive a selection of a product intended
for purchase, from a user. The buyer UI 200 may transmit the
information associated with the selected product (e.g., a vehicle
make, model, mileage, year, dealership, and/or the like) to the
multi-lender layer 212, via the Buy/Sell API 210.
[0062] The API Passthru 214 may receive the information associated
with the selected product of the user from the Buy/Sell API 210, in
the multi-lender layer 212. The API Passthru 214 may forward the
information associated with the selected product to the vault 216.
The vault 216 may decrypt the encrypted information associated with
the selected product, using the encryption service 218. The vault
216 may execute the product eligibility micro-service 104. The
product eligibility micro-service 104 may retrieve product
eligibility information associated with the lenders included in the
subset of lenders, from the lender confidential repository 221. The
product eligibility micro-service 104 may determine, in parallel,
whether the selected product is eligible for a loan from a given
lender based on the information associated with the selected
product and information associated with product eligibility for
each of the respective lenders. The information associated with
product eligibility may be different for each lender. For example,
each lender may have different requirements for make, model, year,
mileage, price, and/or the like. In this regard, the product
eligibility micro-service 104 may determine certain products are
not eligible for loans provided by lenders.
[0063] The product eligibility micro-service 104 may generate
product eligibility results. The product eligibility results may
include one or more lenders from the subset lenders, for which the
product eligibility micro-service 104 determined the selected
product is eligible for a loan. The API Passthru 214 may forward
the product eligibility results to the Buy/Sell API 210. The buyer
UI 200 may render the decrypted product eligibility results on the
buyer UI 200 GUI.
[0064] Continuing with the earlier example, after the product
eligibility results are rendered on the GUI of the buyer UI 200,
the buyer UI 200 may receive a request to build a loan offer for a
selected product, from a user. The request may include information
associated with the desired loan, such as the price of a selected
product, down payment amount, loan amount, tax amount, dealer fees,
service contract, GAP, and/or the like. The buyer UI 200 may
encrypt the information associated with the request for building an
offer and transmit the information associated with the request for
building an offer to the multi-lender layer 212, via the Buy/Sell
API 210. Alternatively, the Buy/Sell API 210 may encrypt the
information associated with the request for building an offer and
transmit the encrypted information associated with the request for
building an offer to the multi-lender layer 212. In yet another
example, the buyer UI 200 may transmit the request including the
information to the multi-lender layer 212, unencrypted, using the
Buy/Sell API 210. The Buy/Sell API 210 may determine that the user
is eligible for a loan from one or more lenders, based on the
prequalification results and the product eligibility results. The
Buy/Sell API 210 can generate pricing offer requests for each of
the one or more lenders and transmit the requests to the
multi-lender layer 212.
[0065] The API Passthru 214 may receive the information associated
with the request for building an offer from the Buy/Sell API 210
and the requests for each of the one or more lenders, in the
multi-lender layer 212. The API Passthru 214 may forward the
information associated with the requests for each of the one or
more lenders for building an offer to the vault 216. The vault 216
may execute the pricing micro-service 108. The pricing
micro-service 108 may retrieve rules or methodologies for
generating pricing structures for each of the one or more lenders,
from the lender confidential repository 221. Generation of the
pricing structure may include using Bayesian regression algorithms,
decision trees, pricing girds or various equations to price a loan
offer. The rules may also provide sources for retrieving certain
information. For example, a lender may need to use the
prequalification results and/or product eligibility results. The
lender may indicate to the pricing micro-service 108 to retrieve
the prequalification results and/or product eligibility results.
Alternatively, or in addition to, the rules may include
instructions to retrieve information from third-party vendors.
Accordingly, the pricing micro-service 106 may retrieve the
information using the third-party vendors. The pricing
micro-service 106 may process and build, in parallel, a loan offer
based on the information associated with the request for building
an offer, for each of the one or more lenders using information
associated with pricing for each of the respective lenders.
Additionally, each lender may use a different methodology for
calculating pricing for a loan offer.
[0066] The pricing micro-service 106 may generate pricing
structures for a loan for the product from various lenders. The
pricing structures may include loan amounts, interest rates, and
terms and conditions of the loan. The vault 216 may encrypt the
offers using the encryption service 218 and transmit the encrypted
product offers the API Passthru 214. The API Passthru 214 may
forward the encrypted offers to the Buy/Sell API 210. In an
example, the Buy/Sell API 210 may decrypt the encrypted offers and
interface with the buyer UI 200 to render the decrypted offers on
the buyer UI 200. Alternatively, the Buy/Sell API 210 may transmit
the encrypted offers to the buyer UI 200. The buyer UI 200 can
decrypt the encrypted offers and render the decrypted offers on the
buyer UI 200.
[0067] The architecture may also include an analytic aggregator
224. The analytic aggregator may be embodied as a micro-service
residing in the vault 216. The analytic aggregator 224 may capture
all of the data generated in the vault 216 for each user (e.g.,
prequalification results, product eligibility results, and offers)
for each lender and store the captured data in the encrypted logs
222. The captured data may be encrypted in a format specific to a
given lender, such that, a lender may only decrypt data from the
encrypted logs 222. A lender may download data logs from the
encrypted logs 222 specifics to the lender itself.
[0068] In an embodiment, the architecture may be associated with a
financial institution (e.g., bank or lender). As an example, the
administrator of the architecture may be a financial institution.
The financial institution may use its own lending platform 232. The
lending platform 232 may include a loan origination system (LOS)
234. The buyer UI 200 may communicate back and forth with the loan
origination system 232 of the lending platform 232 to generate a
loan offer from the financial institution, via the Buy/Sell API 210
and the API Passthru 214 in the multi-lender layer 212. The buyer
UI 200 may communicate back and forth with the loan origination
system 234 of the lending platform 232 to generate a loan offer
from the financial institution, in parallel, with the
micro-processes (e.g., prequalification 102, product eligibility
104, and pricing 108) generating loan offers from various lenders
in the vault 216. The loan offers from the financial institution
may be presented alongside the loan offers from the other lenders
on the GUI of the buyer UI 200.
[0069] In an embodiment, the architecture may include a third-party
loan origination system API 228. In the case, a lender does not
upload information associated with prequalification, product
eligibility, and pricing, the third-party loan origination system
API 228 may generate a loan offer for the lender. The third-party
loan origination system API 228 may communicate back and forth with
the buyer UI 200, via the Buy/Sell API 210 and the API Passthru 214
in the multi-layer lender 212, to generate a loan offer. buyer UI
200 may communicate back and forth with the third-party loan
origination system API 228 of the third-party API to generate a
loan offer from the financial institution, in parallel, with the
micro-processes (e.g., prequalification 102, product eligibility
104, and pricing 108) generating loan offers from various lenders
in the vault 216.
[0070] FIG. 3 is a block diagram illustrating an expanded view of
the experience layer 208 in accordance to an embodiment. The
Buy/Sell API 210 may reside in the experience layer of the
multi-lender architecture. The Buy/Sell API 210 may be used to
interface between clients such as buyer UI 200, seller UI 202, and
Digital retailer 204, and the multi-lender layer.
[0071] The experience layer 208 may further include the customers
micro-service 110, the bookmark micro-service 112, a marketplace
module 301, pricing module 302, an application module 303, an offer
module 304, a seller (e.g., dealer) module 305, and a pricing cache
306. The experience layer 208 may use the market place module 301,
pricing module 302, the application module 303, offer module 304,
dealer module 305, and pricing cache 306 to provide consistent and
reliable pricing structure to a user by storing the pricing,
prequalification, and applications submitted by a user for a
specified period of time.
[0072] The application module 303 may route prequalification
requests to the prequalification micro-service and may receive the
prequalification results. The application module 303 may store
prequalification results in the prequalification database 146. The
prequalification results may be correlated to various users. The
pricing module 302 may route pricing requests to the pricing
micro-service and receive the pricing structures from the pricing
micro-service. The pricing module 302 may store pricing structures
generated for a given product in the pricing database 148. The
pricing structures can be correlated to a user. In an embodiment,
the pricing cache 306 may store pricing structures generated for a
given product for a particular user for a short period of time
(e.g., single session). The offers module 304 may route a purchase
request for a given product for a user to the pricing
micro-service. The offers module 304 may store final pricing
structures offered to a user in the offers database 308.
[0073] The marketplace module 301 may store information associated
with lenders and products. The information the marketplace module
301 may be updated in real-time. For example, a user may apply for
a loan for a product. The Buy/Sell API 210 may filter out lenders
from the marketplace which may not provide loans for the product
based on the personal information of the user or the product
itself. Additionally, as the application for the loan is processed,
each time a lender rejects or approves the loan, the marketplace
module 301 may update the repository. Furthermore, based on the
lenders for which the loans are being processed, the Buy/Sell API
210 can filter out the ineligible products from the marketplace
module 301 which may not be eligible for a loan.
[0074] The seller module 305 may manage the information associated
with different dealers. For example, seller UI 202 may communicate
with the dealer module 305 to retrieve dealer specific information
from the module 305. The dealer specific information may include
dealer requirements for purchasing automobiles, partnerships with
lenders and vendors, dealer inventory, and/or the like.
[0075] The customers micro-service 110 may maintain an association
for prequalification results obtained by a user in the applications
database 146. The bookmark micro-service 112 may capture snapshots
of pricing structures generated for a user and a particular
product. The bookmark micro-service 112 may store and correlate the
user to the pricing structure in the pricing database 148.
[0076] FIG. 4 is an example flowchart 400 for obtaining consistent
pricing for a loan for a product. In operation 402, a
prequalification micro-service may generate a prequalification
result in response to an initial prequalification request for a
user.
[0077] In operation 404, a central system may store the
prequalification in an applications database.
[0078] In operation 406, the central system may generate a pricing
structure for a specified product for a user, based on the
prequalification result.
[0079] In operation 408, a bookmarking micro-service may store the
pricing structure for the specified product for the user in a
pricing database, for a predetermined time frame, in response to
receiving a request to bookmark the pricing structure.
[0080] In operation 410, the central system may receive a pricing
request for the specified product for the user.
[0081] In operation 412, the central system may query the
applications database, using a customer micro-service, to determine
whether a prequalification result for the user exists, based on the
user information.
[0082] In operation 414, in response to determining the
prequalification request for the user exists, the central system
may query the pricing database, using the bookmark micro-service,
to determine whether a pricing structure for the specified product
has been generated for the user in the predetermined time
frame.
[0083] In operation 416, in response to determining a pricing
structure for the specified product has been generated for the user
in the predetermined time frame, the central system may transmit
the pricing structure for the specified product.
[0084] FIG. 5 is an example flowchart 500 for obtaining consistent
pricing for a loan for a product. In operation 502, in response to
receiving an initial prequalification request, the central system
may identify a type of application transmitting the initial
prequalification request.
[0085] In operation 504, the central system may identify a set of
rules tied to the type of application transmitting the initial
prequalification request. Lenders can vary the type of rules and
methodologies used to calculate a prequalification result or
pricing structure based on the type of application transmitting the
request. For example, different methodologies can be used if the
request is transmitted using a seller application, first buyer
application, or second buyer application.
[0086] In operation 506, the central system may process the
prequalification request based on the set of rules to generate the
prequalification result. This can be an actionable prequalification
result. That is, the user can select this prequalification result
to obtain a final loan-pricing offer that includes the same APR and
pricing information for the specific user and product as in the
prequalification result. So, if the user transmitted a pricing
request from a different application within a given timeframe of
transmitting the prequalification request, the system may provide
the final loan pricing offer (e.g., pricing structure) can include
the same details as the prequalification result.
[0087] FIG. 6 is a block diagram of example components of device
600. One or more computer systems 600 may be used, for example, to
implement any of the embodiments discussed herein, as well as
combinations and sub-combinations thereof. Computer system 600 may
include one or more processors (also called central processing
units, or CPUs), such as a processor 604. Processor 604 may be
connected to a communication infrastructure or bus 606.
[0088] Computer system 600 may also include user input/output
device(s) 603, such as monitors, keyboards, pointing devices, etc.,
which may communicate with communication infrastructure 606 through
user input/output interface(s) 602.
[0089] One or more of processors 604 may be a graphics processing
unit (GPU). In an embodiment, a GPU may be a processor that is a
specialized electronic circuit designed to process mathematically
intensive applications. The GPU may have a parallel structure that
is efficient for parallel processing of large blocks of data, such
as mathematically intensive data common to computer graphics
applications, images, videos, etc.
[0090] Computer system 600 may also include a main or primary
memory 608, such as random access memory (RAM). Main memory 608 may
include one or more levels of cache. Main memory 608 may have
stored therein control logic (i.e., computer software) and/or
data.
[0091] Computer system 600 may also include one or more secondary
storage devices or memory 610. Secondary memory 610 may include,
for example, a hard disk drive 612 and/or a removable storage
device or drive 614.
[0092] Removable storage drive 614 may interact with a removable
storage unit 618. Removable storage unit 618 may include a
computer-usable or readable storage device having stored thereon
computer software (control logic) and/or data. Removable storage
unit 618 may be program cartridge and cartridge interface (such as
that found in video game devices), a removable memory chip (such as
an EPROM or PROM) and associated socket, a memory stick and USB
port, a memory card and associated memory card slot, and/or any
other removable storage unit and associated interface. Removable
storage drive 614 may read from and/or write to removable storage
unit 618.
[0093] Secondary memory 610 may include other means, devices,
components, instrumentalities or other approaches for allowing
computer programs and/or other instructions and/or data to be
accessed by computer system 600. Such means, devices, components,
instrumentalities or other approaches may include, for example, a
removable storage unit 622 and an interface 620. Examples of the
removable storage unit 622 and the interface 620 may include a
program cartridge and cartridge interface (such as that found in
video game devices), a removable memory chip (such as an EPROM or
PROM) and associated socket, a memory stick and USB port, a memory
card and associated memory card slot, and/or any other removable
storage unit and associated interface.
[0094] Computer system 600 may further include a communication or
network interface 624. Communication interface 624 may enable
computer system 600 to communicate and interact with any
combination of external devices, external networks, external
entities, etc. (individually and collectively referenced by
reference number 628). For example, communication interface 624 may
allow computer system 600 to communicate with external or remote
devices 628 over communications path 626, which may be wired and/or
wireless (or a combination thereof), and which may include any
combination of LANs, WANs, the Internet, etc. Control logic and/or
data may be transmitted to and from computer system 600 via
communication path 626.
[0095] Computer system 600 may also be any of a personal digital
assistant (PDA), desktop workstation, laptop or notebook computer,
netbook, tablet, smartphone, smartwatch or other wearables,
appliance, part of the Internet-of-Things, and/or embedded system,
to name a few non-limiting examples, or any combination
thereof.
[0096] Computer system 600 may be a client or server, accessing or
hosting any applications and/or data through any delivery paradigm,
including but not limited to remote or distributed cloud computing
solutions; local or on-premises software ("on-premise" cloud-based
solutions); "as a service" models (e.g., content as a service
(CaaS), digital content as a service (DCaaS), software as a service
(SaaS), managed software as a service (MSaaS), platform as a
service (PaaS), desktop as a service (DaaS), framework as a service
(FaaS), backend as a service (BaaS), mobile backend as a service
(MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid
model including any combination of the foregoing examples or other
services or delivery paradigms.
[0097] Any applicable data structures, file formats, and schemas in
computer system 600 may be derived from standards including but not
limited to JavaScript Object Notation (JSON), Extensible Markup
Language (XML), Yet Another Markup Language (YAML), Extensible
Hypertext Markup Language (XHTML), Wireless Markup Language (WML),
MessagePack, XML User Interface Language (XUL), or any other
functionally similar representations alone or in combination.
Alternatively, proprietary data structures, formats or schemas may
be used, either exclusively or in combination with known or open
standards.
[0098] In some embodiments, a tangible, non-transitory apparatus or
article of manufacture comprising a tangible, non-transitory
computer useable or readable medium having control logic (software)
stored thereon may also be referred to herein as a computer program
product or program storage device. This includes, but is not
limited to, computer system 600, main memory 608, secondary memory
610, and removable storage units 618 and 622, as well as tangible
articles of manufacture embodying any combination of the foregoing.
Such control logic, when executed by one or more data processing
devices (such as computer system 600), may cause such data
processing devices to operate as described herein.
[0099] Embodiments of the present disclosure have been described
above with the aid of functional building blocks illustrating the
implementation of specified functions and relationships thereof.
The boundaries of these functional building blocks have been
arbitrarily defined herein for the convenience of the description.
Alternate boundaries may be defined so long as the specified
functions and relationships thereof are appropriately
performed.
[0100] The foregoing description of the specific embodiments will
so fully reveal the general nature of the disclosure that others
may, by applying knowledge within the skill of the art, readily
modify and/or adapt for various applications such specific
embodiments, without undue experimentation, without departing from
the general concept of the present disclosure. Therefore, such
adaptations and modifications are intended to be within the meaning
and range of equivalents of the disclosed embodiments, based on the
teaching and guidance presented herein. It is to be understood that
the phraseology or terminology herein is for the purpose of
description and not of limitation, such that the terminology or
phraseology of the present specification is to be interpreted by
the skilled artisan in light of the teachings and guidance.
[0101] The breadth and scope of the present disclosure should not
be limited by any of the above-described exemplary embodiments but
should be defined only in accordance with the following claims and
their equivalents.
* * * * *