Patent Application
20180053172
Companies often use their websites and mobile applications to promote customer shopping, loyalty, sales, and related interaction. The website and mobile applications will include shopping hours for their brick-and-mortar stores, advertisements, coupons, rewards information, specials, directions, locations, and the like. When a customer accesses the website or application on a large screen such as a desktop screen, laptop screen, notepad screen, tablet screen or the like, the website or application can provide significant user interaction. For example, numerous different web pages can be opened by the customer, e.g., links from within the website or application can open new tabs, different windows, or the like. Moreover, these actions may depend upon customer settings and the like.
However, on a smaller device, such as a mobile device, e.g., where real estate on the computing device screen is limited, there is a need to provide the customer information without numerous pop-ups, tabs, pages, and the like.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate various embodiments and, together with the Description of Embodiments, serve to explain principles discussed below. The drawings referred to in this brief description should not be understood as being drawn to scale unless specifically noted.
Reference will now be made in detail to embodiments of the subject matter, examples of which are illustrated in the accompanying drawings. While the subject matter discussed herein will be described in conjunction with various embodiments, it will be understood that they are not intended to limit the subject matter to these embodiments. On the contrary, the presented embodiments are intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the various embodiments as defined by the appended claims. Furthermore, in the Description of Embodiments, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present subject matter. However, embodiments may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure information of the described embodiments.
Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present Description of Embodiments, discussions utilizing terms such as “selecting”, “outputting”, “inputting”, “providing”, “receiving”, “utilizing”, “obtaining”, “updating”, “accessing”, “changing”, “correlating”, “prescreening”, “developing”, “presenting” or the like, often refer to the actions and processes of an electronic computing device/system, such as a desktop computer, notebook computer, tablet, mobile phone, and electronic personal display, among others. The electronic computing device/system manipulates and transforms data represented as physical (electronic) quantities within the circuits, electronic registers, memories, logic, and/or components and the like of the electronic computing device/system into other data similarly represented as physical quantities within the electronic computing device/system or other electronic computing devices/systems.
Seamless integration of financial information within a mobile retail application framework is discussed herein. When it comes to consumer privacy a financial institution, such as a bank or the like, must operate within the constraints of a number of rules, laws and statutes. Additionally, these rules, laws and statutes can differ by country, state, county, and city. Moreover, the rules, laws and statutes can and do change over time. As such, the financial information cannot be stored in the same data warehouses as those used by retailers. Moreover, the information accessible by a retailer's application stored at a retailer's database is legally limited to not include the customer's financials.
Thus, by regulation, financial institutions cannot hand over functionality to outside servers even via API's and SDK's. In other words, in the banking/financial industry, regulations control what portions of functions or proxies can be unloaded from the financial side to the customer side. As a result financial institutions are not able to use conventional practices such as API's, SDK's or the like to provide in-app functionality. I
Embodiments described herein create a financial functionality that plugs into an existing native retailer application to give the customer a seamless experience. For example, if the customer is using the retailer application, they can seamlessly transition to related financial data such as their credit balance, transaction history, rewards certificates, or the like. These aspects of financial data can include shopping data, account management information, available offers, or other functionality which the consumer receives from their financial account.
When using the plugin, from the customer or retailer perspective the app will appear to be a single application, e.g., seamless. However, from the financial institution's and retail server's actual underlying operation, the portion of the financial information provided by the plugin will actually be provided by financial server 120 and not available to the retail application including the underlying retail application server 110 that the retailer application is utilizing. In other words, the technology is not an application program interface (API) or a software development kit (SDK) as they do not meet the regulatory requirements necessary to maintain the financial information separation/compartmentalization. Instead, the plugin is used in order to comply with the regulations and maintain the proper separation/compartmentalization/security of the customer financial information.
Importantly, the embodiments of the present invention, as will be described below, provide an approach for seamless integration of financial information within a mobile retail application framework which differs significantly from the conventional processes used by native applications. In conventional approaches, the application has access to all of the data being ported through it. Here, the present embodiments, as will be described and explained below in detail, provide a previously unknown procedure to protect the financial information from the application while allowing the information to be displayed within the framework of the application, e.g., from request for financial information, through presentation of the received information. Moreover, the present embodiments provide real-time presentation of the financial information from within the framework of the underlying native application via the plugin. Thus, embodiments of the present invention provide an approach for seamless integration of financial information within a mobile retail application framework which extends well beyond what was previously done by hand.
As will be described in detail, the various embodiments of the present invention do not merely implement conventional retail application processes on a computer. Instead, the various embodiments of the present invention, in part, provide a previously unknown procedure to seamlessly integrate financial information within a mobile retail application framework. Moreover, the present embodiments provide the integrated financial information within a mobile retail application framework without providing the financial information stored on financial server 120 from being accessed by retail application server 110 providing any information to the retailer's application. Hence, embodiments of the present invention provide a novel process for seamless integration of financial information within a mobile retail application framework which is necessarily rooted in computer technology to overcome a problem specifically arising in the realm of real-time financial information and retailer information collaboration for a shared customer.
Moreover, the embodiments do not recite a mathematical algorithm; nor do they recite a fundamental economic or longstanding commercial practice. Instead, they address a business challenge of accurate and timely seamless integration of financial information within a mobile retail application framework. Thus, the embodiments do not “merely recite the performance of some business practice known from the pre-Internet world along with the requirement to perform it on the Internet.” Instead, the embodiments are necessarily rooted in retail and financial technology in order to overcome a problem specifically arising in the realm of seamless integration of financial information within a mobile retail application framework.
With reference now to
For purposes of the discussion, mobile device 101 may be a mobile phone, a smart phone, a tablet, a smart watch, a piece of smart jewelry, smart glasses, or other user portable computational devices having wireless connectivity. That is, mobile device 101 would be capable of broadcasting and receiving via network 105. In one embodiment, mobile device 101 may have a positioning determining system. In another embodiment, mobile device 101 may be able to determine location within a given radius, such as the broadcast range of a beacon, WiFi hotspot, overlapped area covered by a plurality of mobile telephone signal providers, or the like. In general, mobile device 101 will have an operating system and one or more application operating thereon.
Retail application server 110 maintains retail information such as sales, inventory, locations, and the like. Moreover, retail application server 110 maintains customer information such as purchase information, order history, rewards points, loyalty rewards, savings offers, coupons, location information, goods searches, and the like. The application etc. In one embodiment, the mobile retail application on mobile device 101 accesses retail application server 110 via network 105.
Financial server 120 provides client information such as, information may include financial data such as their credit balance, remaining credit available, transaction history, rewards certificates, money spent this month, prior purchases, and the like. In one embodiment, the mobile retail application on mobile device 101 accesses financial server 120 on a secure channel via network 105.
Referring now to
In general, screenshot 201 shows a retailer mobile application homepage as presented on mobile device 101. Screenshot 202 illustrates a secure financial home page as presented by the financial plugin within the framework of the retail mobile application on mobile device 101. Screenshot 203 is a secure credit summary page as presented by the financial plugin within the framework of the retail mobile application on mobile device 101. Screenshot 204 shows a digital credit “card” within the framework of the retail mobile application as presented on mobile device 101. Screenshot 205 illustrates a secure financial transaction history page as presented by the financial plugin within the framework of the retail mobile application on mobile device 101. Screenshot 206 is a secure financial bill payment page as presented by the financial plugin within the framework of the retail mobile application on mobile device 101. Screenshot 207 illustrates a digital reward certificate presented by the retail mobile application on mobile device 101.
With reference now to
Moreover, in one embodiment, mobile device 101 may automatically open the application when the device is within a proximal location to David's tool shed. For example, mobile device 101 may have a positioning determining system or be able to determine location within a given radius, such as the broadcast range of a beacon, WiFi hotspot, overlapped area covered by a plurality of mobile telephone signal providers, or the like. The application would have a geo-fence or the like that would automatically launch the application on mobile device 101 when the user was within a certain range that may be user definable. For example, the range may be, when entering David's tool shed; 100 feet therefrom, e.g., in the parking lot; 500 meters therefrom, e.g., in the mall; within 2 miles thereof; or the like.
Referring now to 320 of
With reference now to 330 of
With reference now to 340 of
Referring now to 350 of
With reference now to 360 of
Thus, when using the plugin, from the customer or retailer perspective the app will appear to be a single application, e.g., seamless. However, although the information from the financial plugin would be presented as though it were part of the retail application, from the financial institution's and retail server's actual underlying operation; the portion of the financial information provided by the plugin will actually be provided by financial server 120. That is, it will not be available to the retail application including the underlying retail application server 110 that the retailer application is utilizing.
In other words, the technology is not an application program interface (API) or a software development kit (SDK) as they do not meet the regulatory requirements necessary to maintain the financial information separation/compartmentalization. Instead, the plugin is used in order to comply with the regulations and maintain the proper separation/compartmentalization/security of the customer financial information.
In addition, the technology is well suited to utilize the information of the credit account in conjunction with a purchase request of the retail application to adjust a user's credit limit based on the purchase request. For example, if a user is looking at purchasing something for 500 dollars but has less than 500 dollars in credit remaining on their account. The application may work with the financial plugin to determine the difference and perform a credit reevaluation. In so doing, the result of the credit reevaluation may be an increase in the user's credit limit to allow a purchase of a product at an amount higher than a user's present credit limit. That is, the application in conjunction with the financial plugin could determine that the user would be able to receive an increase in the credit limit. In general, the determination may be based on a credit check, the user's credit history with the information provided in the financial plugin, an intended credit increase by the financial services accessed by the financial plugin, and the like.
Moreover, in one embodiment, the retail application and plugin will allow the user to use their credit account to make a purchase via the retail application without requiring the user to present their plastic card. Similarly, the user would not be required to use mobile pay that includes transfer of information between mobile device 101 and the POS at the checkout. Instead, the payment portions of the checkout would be performed completely within the application running on the user's mobile device 101.
Thus, embodiments described herein create a financial functionality that plugs into an existing native retailer application to give the customer a seamless experience. For example, if the customer is using the retailer application, they can seamlessly transition to related financial data such as their credit balance, transaction history, rewards certificates, or the like. These aspects of financial data can include shopping data, account management information, available offers, or other functionality which the consumer receives from their financial account.
The distribution of the plugin provides a turnkey solution to retailers while ensuring that the communication and data storage of financial information meets all standards, statutes and requirements. The plugin provides the end user with the account center core services that can fit seamlessly into most app experiences. The following is one embodiment which can be used by developers to integrate the Plugin into their app.
The description provided herein for Integrating the Plugin is directed toward the following: Android Studio with Gradle version 1.2+, Android 2.3 (API Level 9) or greater; Note that when running the plugin on versions less than Android 4.0 (API Level 14), some functionality may be lost.
To obtain and integrate the plugin via Gradle, add the following repository section to the app's build.gradle file.
Then, add the following dependencies to the build.gradle file:
To obtain and integrate the plugin manually, download the latest release ZIP or tarball from: <insert url here>. Unzip the archive. Copy the extracted accountcenter.aar file into the app/libs directory in the application.
Add the libs directory as a flatdir to the top-level repositories section of the app's build.gradle file:
Add the following to dependencies (where accountcenter is the .aar file name) in build.gradle to compile the aar:
Once the plugin and following dependencies have been included in gradle, make sure that a project sync and build complete successfully. The plugin can be added to the host application using the AllianceNPI fragment. Use the following code to launch the fragment (the items in bold should be changed appropriately per integration):
public View onCreateView(LayoutInflater inflater, ViewGroup
retailer name>”, “<insert api key>”);
To use the NAC as a standalone fragment use a fragmentTransaction.add instead of replace.
<insert retailer name>”, “<insert api key>”);
To properly handle hardware back button presses within the plugin, control must be passed to the plugin from the Activity instance in the app.
The Financial Plugin supports portrait orientation only. Be sure to add:
android:screenOrientation=“portrait” to the activity configuration in the manifest that will launch the fragment containing the Plugin.
To show the NAC in a tabbed view which uses ViewPager, set off screen page limit to be the total number of tabs in the app.
The NAC's container inside the client app should be kept at a consistent size and should not resize when the keyboard is present. One option is to use something similar to the code below within the AndroidMaifest.xml for the activity which is hosting the NAC. android:windowSoftInputMode=“adjustPan”
*Note this is not always required but is needed in most cases.
In some instances it will become necessary to call the onDestroy method for the AllianceNPI in order for the user state to be maintained. If there are no issues with maintaining the user state then this section of integration may be unnecessary.
One situation when this could be necessary is when creating the AllianceNPI fragment from another fragment. When the host fragment is destroyed the AllianceNPI's lifecycle methods do not get executed.
To remedy this add the below section to the host fragment.
Proguard should be used when creating a release version of the plugin. Here is a proguard configuration that can be used to minify and obscure the plugin while retaining appropriate class names.
The description provided herein for Integrating the Plugin is directed toward the following: Xcode 7.1 or greater, an app targeted to iOS 8 or greater.
Download the latest release ZIP or tarball from: https://msl.test2.mycardcare.com/files/beta/ios/ and unzip the archive.
Drag and drop the following files into the Xcode project:
Go to the “Build Phases” tab of the project settings and ensure that libADSAccountCenter.a is listed in the “Link Binary with Libraries” section with mode set to “Required”. If not, click the “+” icon and add them. Next and the following Binaries:
Once the Plugin has been integrated with the Xcode workspace, verify Xcode can compile, link and run (in the iOS Simulator).
Import the following headers:
#import<ADSAccountCenter/ADSAccountCenter.h>into any class which will access the Plugin. Particularly, the AppDelegate will need the headers imported.
Setup the Plugin in the Application's AppDelegate. Insert the following code into application:DidFinishLaunchingWithOptions: in the AppDelegate:
The above method must be called immediately during application:DidFinishLaunchingWithOptions: in the AppDelegate. This is a requirement of the Plugin.
Note that the retailerConsumerAPlKey is the Application Analytics ID from Omniture. This is a value that should be provided for integration. Additionally, this value should be different for the various environments.
The Plugin can be queried to ask whether it is setup by calling:
Once the Plugin is known to be setup, it can be presented to the user via two different methodologies: full-screen, or embedded inside of a container view. The full screen method is for apps that want the Plugin experience to be full-screen until the user touches a “Back” button. The embedded mode is for embedding inside of another View or View Controller, such as a UITabBarController, etc.
To present the Plugin in a full-screen experience, use the following:
To present the Plugin in an embedded view, use the following method in viewDidAppear or viewWillAppear of the view controller embedding the view:
This method assumes that the containerView parameter is a subclass of UIView that is contained as a subview of the viewController parameter.
Important:
For this to display properly, it must be done on a container view that is fully laid out.
Calling this the first time (only the first time) viewDidAppear or viewWillAppear is called for the view controller.
Embedded views should use a view that is pinned to the edges of the view controller's top-level view.
Note: Both of these methods should only ever be called once, and additionally, they are mutually exclusive. Only one of these methods should ever be called in an application.
Be sure to import the Account Center headers into the class which will use either the presentlnWindow or embedlnContainerView to manage the presentation:
When submitting to the App Store, an Entitlements error may be received. This is due to the fact that the user must codesign the ADS Account Center bundle themself. To fix this error, delete ADSAccountCenter from within the ADSAccountCenter.bundle. This will cause Xcode to codesign properly and should enable App Store submissions.
With reference now to
Although
Computer system 400 of
Computer system 400 of
System 400 also includes computer usable non-volatile memory 410, e.g., read only memory (ROM), coupled to bus 404 for storing static information and instructions for processors 406A, 406B, and 406C. Also present in system 400 is a data storage unit 412 (e.g., a magnetic disk drive, optical disk drive, solid state drive (SSD), and the like) coupled to bus 404 for storing information and instructions. Computer system 400 also includes an optional alpha-numeric input device 414 including alphanumeric and function keys coupled to bus 404 for communicating information and command selections to processor 406A or processors 406A, 406B, and 406C. Computer system 400 also includes an optional cursor control device 416 coupled to bus 404 for communicating user input information and command selections to processor 406A or processors 406A, 406B, and 406C. Optional cursor control device may be a touch sensor, gesture recognition device, and the like. Computer system 400 of the present embodiment also includes an optional display device 418 coupled to bus 404 for displaying information.
Referring still to
Computer system 400 also includes an I/O device 420 for coupling system 400 with external entities. For example, in one embodiment, I/O device 420 is a modem for enabling wired or wireless communications between system 400 and an external network such as, but not limited to, the Internet or intranet. A more detailed discussion of the present technology is found below.
Referring still to
System 400 also includes one or more signal generating and receiving device(s) 430 coupled with bus 404 for enabling system 400 to interface with other electronic devices and computer systems. Signal generating and receiving device(s) 430 of the present embodiment may include wired serial adaptors, modems, and network adaptors, wireless modems, and wireless network adaptors, and other such communication technology. The signal generating and receiving device(s) 430 may work in conjunction with one or more communication interface(s) 432 for coupling information to and/or from system 400. Communication interface 432 may include a serial port, parallel port, Universal Serial Bus (USB), Ethernet port, Bluetooth, thunderbolt, near field communications port, WiFi, Cellular modem, or other input/output interface. Communication interface 432 may physically, electrically, optically, or wirelessly (e.g., via radio frequency) couple system 400 with another device, such as a mobile telephone, radio, or computer system.
The computing system 400 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the present technology. Neither should the computing environment be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example computing system 400.
The present technology may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular abstract data types. The present technology may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer-storage media including memory-storage devices.
The foregoing Description of Embodiments is not intended to be exhaustive or to limit the embodiments to the precise form described. Instead, example embodiments in this Description of Embodiments have been presented in order to enable persons of skill in the art to make and use embodiments of the described subject matter. Moreover, various embodiments have been described in various combinations. However, any two or more embodiments may be combined. Although some embodiments have been described in a language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed by way of illustration and as example forms of implementing the claims and their equivalents.
This application claims priority to and benefit of co-pending U.S Provisional Patent Application No. 62/376,824 filed on Aug. 18, 2016, entitled “SEAMLESS INTEGRATION OF FINANCIAL INFORMATION WITHIN A MOBILE RETAIL APPLICATION FRAMEWORK” by David Nack et al., and assigned to the assignee of the present application, the disclosure of which is hereby incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62376824 | Aug 2016 | US |
