WO2020096619A1

WO2020096619A1 - Dynamic card acceptance infrastructure

Info

Publication number: WO2020096619A1
Application number: PCT/US2018/060108
Authority: WO
Inventors: Deepa NAYAK
Original assignee: Visa International Service Association
Current assignee: Visa International Service Association
Priority date: 2018-11-09
Filing date: 2018-11-09
Publication date: 2020-05-14
Anticipated expiration: 2021-05-09

Abstract

A computerized method for providing an interactive graphical user interface (GUI) to a user on a display of a mobile device of the user. The method interacts with the user to obtain acceptance information about non-cash payment device of the merchant. The method further constructs a data structure based on the obtained information. The data structure is stored in a database accessible by an analysis server. The method further transmits the acceptance information stored in the database to the analysis server for additional input to the data structure. The method verifies the data received from the database and provides a tabular report based on the verified data in response to a request.

Description

DYNAMIC CARD ACCEPTANCE INFRASTRUCTURE

Field of the invention

[0001] Embodiments of the invention generally relate to identifying locations that accept certain payment devices.

Background

[0002] Non-cash payment mechanisms or means, such as credit cards, debit cards, mobile payments, contactless payments, etc., have drastically change spending habits for consumers. These devices have evolved overtime; from a plastic card with magnetic stripes to cards with advanced security technology such as (EMV) cards. Other functionalities have also added such as contactless devices or transponders have embedded into the cards themselves.

[0003] Moreover, with the versatility of mobile devices and the software installed thereon (e.g., apps), convenience of making payments has further increased when payment mechanisms have transformed to the software installed on the mobile devices. Contactless hardware chips are now commonplace in mobile devices (e.g., mobile phones and smartwatches) to enable consumers to link the mobile devices to accounts associated with their cards for payments. With the stronger security mechanisms available on the mobile devices, it is even more reliable than the physical card itself.

[0004] However, the biggest drawback of using these non-cash payment means is merchant’s inability to accept non-cash payments. This may be due to the merchant’s unwillingness to pay for the extra cost charged by payment processors or simply due to the lack of reliable connectivity to the payment processors. The consumers, on the other hand, sometimes will not realize the merchant’s lack of acceptance in advance. For example, a consumer may go to a merchant and may be ready to check out at the register, but the merchant may indicate that, unfortunately, that it does not accept non-cash payments and that there are no ATM close by. Alternatively, the merchant may require a minimum amount of purchase before accepting a non-cash payments or may charge additional fees. Either way, the consumers usually are in the dark about the availability of such information and there is no easy way to consume such information.

[0005] Similarly, there may be merchants that accept non-cash payment devices but restricted to a certain type or ones from a certain country.

[0006] Therefore, embodiments of the invention attempt to solve or address one or more of the problems identified.

Summary of the invention

[0007] Embodiments of the invention may provide an easy to use platform to report and edit information about merchants, especially for those that do not accept non-cash payment mechanisms or devices or for those that accept non- cash payment mechanisms or devices with conditions. Aspects of the invention provide a platform that further communicates with the user-provided information with a known database that not only reconcile but further supplement the database. Further embodiments of the invention provide an application programming interface (API) to interact with other services to enable

interoperability of the platform and/or databases from other service providers. Brief description of the drawings

[0008] Persons of ordinary skill in the art may appreciate that elements in the figures are illustrated for simplicity and clarity so not all connections and options have been shown to avoid obscuring the inventive aspects. For example, common but well-understood elements that are useful or necessary in a commercially feasible embodiment may often not be depicted in order to facilitate a less obstructed view of these various embodiments of the present disclosure. It will be further appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein may be defined with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.

[0009] FIG. 1 is a diagram illustrating a graphical user interface (GUI) on a mobile device according to one embodiment of the invention.

[0010] FIG. 2 is a diagram illustrating another GUI on a mobile device according to one embodiment of the invention illustrated in FIG. 1.

[0011] FIGS. 3A-3F are diagrams illustrating GUIs on a mobile device according to one embodiment of the invention.

[0012] FIG. 4 is a diagram illustrating a data structure of a merchant acceptance information according to one embodiment of the invention. [0013] FIG. 5 is a diagram illustrating a system according to one embodiment of the invention.

[0014] FIG. 6A is a table illustrating a report of a merchant acceptance

information according to one embodiment of the invention.

[0015] FIG. 6B is a diagram of a heat map illustrating another presentation

according to one embodiment of the invention.

[0016] FIG. 7 is a flowchart illustrating a computerized method according to one embodiment of the invention.

[0017] FIG. 8 is a diagram illustrating a portable computing device according to one embodiment of the invention.

[0018] FIG. 9 is a diagram illustrating a remote computing device according to one embodiment of the invention.

Detailed Description

[0019] The present invention may now be described more fully with reference to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific exemplary embodiments by which the invention may be practiced. These illustrations and exemplary embodiments may be presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and may not be intended to limit any one of the inventions to the embodiments illustrated. The invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. Among other things, the present invention may be embodied as methods, systems, computer readable media, apparatuses, or devices. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. The following detailed description may, therefore, not to be taken in a limiting sense.

[0020] Aspects of the invention provide a dynamic card acceptance infrastructure with data mining, crowdsourcing, and artificial intelligence. Embodiments of the invention further build a uniform database structure and application programming interface (API) such that use of the database structure and/or data packets embodying aspects of the invention may be accomplished.

[0021] In one embodiment, elements of the invention may assist in

supplementing and updating existing database that may have some information relating to the card acceptance of merchants or stores. As such, in this “verification mode,” embodiments of the invention assist a system to update and modify the database.

[0022] On the other hand, aspects of the invention may also create new entries into the infrastructure when a user or consumer discovers new merchants at a new location or at an existing location but under a different management. As such, in this“discovery mode,” embodiments of the invention enable the system to interact with the user in creating new entries in the infrastructure. [0023] Moreover, with a defined data packet protocol or schema, embodiments of the invention provide flexibility in enriching the infrastructure by having APIs for other service providers or software to making the infrastructure more robust.

[0024] Referring now to FIG. 1 , an exemplary graphical user interface (GUI) on a mobile device 100 may be used to illustrate an exemplary use scenario to further illustrate aspects of the invention. For example, the mobile device 100 may be a smartphone, a tablet computer, a laptop, a smartwatch, a smart glasses, or a device with network connectivity and image capturing devices (e.g., a vehicle or a drone). The mobile device 100 may include a physical screen for displaying objects to a user and may include input components or elements to receive inputs from the user. It is to be understood that the mobile device 100 may provide output such as audio to user, instead visual renderings on the display. It is also to be understood that the user may provide audio input or other inputs (e.g., tactile or gesture) to the mobile device 100 to interact with the mobile device. Flowever, for the sake of simplicity and not as a limitation, FIG. 1 illustrates a visual embodiment of the invention as an exemplary use scenario.

[0025] In this embodiment, a graphical user interface (GUI) 102 may be

presented on the mobile device 100 via an application (“app”) or software installed thereon. For example, the mobile device 100 may be a device similar to that of a device 801 in FIG. 8 that includes a processor and a memory for storing an operating system that provides an execution environment for the app or software to be executed. In another embodiment, the GUI 102 be instantiated or executed directly by the operating system as a module. [0026] The GUI 102 may provide icons or buttons to interact with the user. For example, the GUI 102 may provide a header 104 for the app or software. Initially, the user may be presented with the GUI 102 to participate in the dynamic card acceptance infrastructure. In this example, the user may choose either a login box 106, a box 108 for a user who does not wish to sign up as a member but wish to contribute as a guest, or a box 110 to sign up. In the embodiment where the user selects box 108, the user may be directed to a GUI (not shown) to enter his or her contact information if he or she wishes to be contacted. In another embodiment where the use selects box 110 to sign up, the user may be directed to another GUI (not shown) to enter his or her information, such as name, contact information, etc. It is to be understood that these GUIs driven from box 108 and 110 may request other information without departing from the scope or spirit of embodiments of the invention.

[0027] In one embodiment, the app or software may be used as part of an

employee program. In another embodiment, the app or software may be available to the general public as it may use the force of crowdsourcing to make the infrastructure more robust. As such, the user may be automatically signed up or signed in when the user enters the place of employment (e.g., geolocation devices in the mobile device may“check-in” the user automatically when the mobile device of the user is within range of the place of employment).

[0028] Referring now to FIG. 2, another GUI 202 illustrates interactive elements from the app or the software. In one embodiment, the GUI 202 is transitioned from the GUI 102 after the user has completed the log in process, e.g., after selecting the box 106 or after entering the requested information from the sign up process. For example, after the user selects box 110 and after entering the information to sign up for an account, the user may be taken back to the GUI 102 to sign-in to the app or the software.

[0029] Still referring to FIG. 2, the GUI 202 may provide the heading of the app or the software 14, a box 204 displaying the user’s name, and a new box 206 for the user to contribute to or engage with the app or software. In one example, the box 206 includes an entry field 208 to enter the name of a merchant in question. For example, after the user taps or touches on the field 208, the app or software may provide a virtual keyboard for the user to enter the name of the merchant in the field 208. In another example, the app or software may display another input method, such as a microphone icon for the user to provide audio input for the app or software to identify the name of the merchant. It is to be understood that other gestures or input approaches may be employed by the app or the software, or the mobile device without departing from the scope or spirit of embodiments of the invention.

[0030] The GUI 202 may also provide a“YES” icon 210 and a“NO” icon 212 to the user to respond to the question presented on the GUI 202:“DOES TH IS MERCHANT ACCEPT NON-CASH PAYMENT?” in the box 206. The icon 210 may enable the user to answer the question positively while the icon 212 may enable the user to note a negative answer to the question.

[0031] In one embodiment, the non-cash payment mechanism or device may be in the form of a plastic card with magnetic stripes or EMV chips. In another embodiment, the non-cash mechanism or device may be a contactless plastic card. In a further embodiment, the non-cash payment mechanism or device may be a mobile phone with short-distance transceiver that interacts with a receiving terminal to exchange payment information.

[0032] Referring now to FIG. 3A, another GUI 302 provides a new set of

interactive items to the user after transitioned from the GUI 202 in response to a selection of the icon 212. The GUI 302 may include a title box 304 for the app or software, a user box 306 indicating the username or the name of the user who has signed into the account, and a new box 308 for further details from the user. As shown in the GUI 202, the user was asked whether the merchant in box 208 accept non-cash payments. As such, the box 308 may provide a dynamic list of questions 310 to solicit or request additional information from the user. For example, the questions 310 may include at least one or more of the following: a picture, a pin location on a map app or webpage, a web hyperlink, a website address of the merchant, a social media page or post by staff or owner of the merchant, an intersection, a voice entry of the location of the merchant, or other descriptions such as fagade or storefront that may uniquely identify the merchant In another embodiment, each type or category of the information to be provided from questions 310 may be direct or firsthand information from the user as the user may readily retrieve or provide the information requested. In another embodiment, the questions 310 may be dynamic in the sense that other questions may be included in response to one or more other questions in the list 310 or other information that is already included in the infrastructure. [0033] In one embodiment, the user may respond to one of the questions 310 by selecting affirmatively using an indicator 312. In the example shown in FIG. 3, the user selects“PICTURE” is a type of information that the user may wish to provide to the infrastructure to identify the merchant.

[0034] As such, the user may be transitioned to a GUI 322 with additional

interactive elements. The GUI 322 may include a box 324 that may interact with the user to provide the actual information indicated by the indicator 312. For example, in this instance illustrated in FIGS. 3A and 3B, the user has selected “PICTURE” as the information to be provided. As such, the box 324 may include a quick reference or label 326:“UPLOAD A PHOTO OF THE TERMINAL OR STOREFRONT,” as a reminder. The GUI 322 may further include a button 328 for“CAMERA” to enable the user to use a camera device that is connected or engaged with the mobile device 100 to capture the merchant’s storefront, the address tag, or other identifying information of the merchant. The box 324 may also provide a button 330 for“STORED PHOTO” for the user to retrieve a previously taken or captured photo from a memory storage of the mobile device. For example, the user may have already taken a picture or the user may receive the picture from someone else who was able to provide the picture to the user. In another embodiment, the box 324 may also include a box 332 that may illicit additional information from the user from the box 324, such as a telephone number of the merchant. Once the user is ready to provide the information, the user may select a button 336 to“SUBMIT” or a button 334 to go“BACK” to the GUI 302 to select another category of information for the infrastructure. [0035] In one embodiment, once the user selects the button 336 to submit the information, e.g., the picture, the user may be transitioned back the GUI 302 to provide additional information that the user may wish to provide. In another embodiment, the user may be transitioned a GUI 342 as shown in FIG. 3E. in FIG. 3E, the GUI 342 may display a message 344 thanking or congratulating the user for its contribution of the information provided to the infrastructure. In another embodiment, the GUI 342 may further provide a box 346 showing a number of points assigned for such contribution. In the example of employee programs as discussed above, the box 346 may indicate the number of points the user may receive. The GUI 342 may also provide a button 350“SUBMIT” and a button 348“BACK.” The button 350 may enable the user to submit additional information, such as the GUI 302, while the button 348 may take the user back to the initial screen of the GUI 102 or 202 or exiting the app or software.

[0036] Data that is received via the box 208, the icons 210 and 212, the indicator 312, the image and the analysis thereof via the box 328 or 330, the telephone number from 332, etc., may be entered or inputted via data feed to a data structure 402, to be discussed later. In one embodiment a server system, such as that described in FIG. 9, may already have a database that store records each having a data structure similar to that of the data structure 402. Embodiments of the invention build upon the data structure 402 to provide a flexible database such that not only data in the database may be added by users but also may be fed for further analysis and process. [0037] Referring back to FIG. 2, in the embodiment where the user may select the icon 210 (e.g., a positive response to the question), the GUI 202 may be transitioned to another GUI 362 in FIG. 3C. This GUI 362 may represent a set of conditions that the merchant may impose for accepting non-cash payments. For example, the GUI 362 includes a box 364 that includes a set of questions 366, such as: a minimum amount needed to spend by a customer before he or she could use a non-cash payment, non-cash payment devices may be accepted unless those are issued by local or regional banks (e.g., no foreign banks or issuers), extra fees may be charged against the user if the non-cash payment devices were used, government identification, such as passport, is required when using the non-cash payment devices, the non-cash payment devices may only be used within a certain period of operation of the merchant (e.g., for safety issues), the non-cash payment devices may be used toward a purchase of a certain kind of products, the merchant may accept contactless non-cash payment devices, or other conditions not listed. The user may interact with the box 364 and or each of the questions 366 by placing an indicator 368, either via a physical interaction (e.g., a command, touch, or gesture) or an audio interaction (e.g., a voice command or sound) to select one of the conditions that the user may wish to provide about the restrictions or conditions for using a non-cash payment device at the merchant. In this example, the user may wish to provide information about the“minimum spending amount” in order to use a non-cash payment device by placing the indicator 368. [0038] Upon indicating that, the user may be transitioned to FIG. 3D. A GUI 382 may provide a box 384 to receive additional information from the user regarding the restriction related to the“minimum spending,” as indicated by the indicator 368 in the GUI 362. For example, a first sub-information 386 may be the amount of the minimum spending. The GUI 382 may provide about 3 options, such as “5,”“10,” or“OTFIER.” In one embodiment, depending on the size or resolution of the display of the mobile device 100, the box 384 may provide options to question 386 more than 3 that are currently shown.

[0039] The box 384 in the GUI 382 may further include a second sub-information 388 that may further define the currency. For example, the currency shown may include USD $, UK £, or OTFIER. Again, similar to the above, in one

embodiment, depending on the size or resolution of the display of the mobile device 100, the box 384 may provide options to the question 388 more than 3 that are currently shown.

[0040] The GUI 382 may further include an additional box 390 that requests

additional information from the user, such as“WFIETFIER TFIE MERCFIANT ACCEPTS CONTACTLESS PAYMENT DEVICE?” It is again understood that other questions may be provided in the box 390. In another embodiment, the box 390 may include more than one question and one of the questions may be from question 368.

[0041] In this embodiment, after the user has selected answers or options from the questions 386 and 388, the user may then select a button 392 to“SUBMIT,” or a button 394“BACK,” to go back to the GUI 362. [0042] Referring to FIG. 3F, an alternative embodiment of the invention shows a GUI 395 that may be presented to the user after the user selects the box 350.

For example, the GUI 395 may be presented after the user has entered more than one piece of information for the merchant, whether the information is received from the GUI 322 or the GUI 382. As such, the GUI 395 may include a new box 396 with a slightly different message of“YOU FIAVE 3 MORE POINTS.” The GUI 395 may also present a box 397 for additional information to be entered by the user and may present a“SUBMIT” button 399 or a“BACK” button 398.

[0043] It is to be understood that while FIGS. 3A to 3F may appear to show that the GUI appears to be discrete screen page (e.g., transitioned from GUI 202 to 302), other rendering techniques may be used without having the GUI appears to be a page-to-page transition. For example, a next GUI may fade, reveal, or fly into view for the user. As such, different techniques to transition between the GUIs may be employed without departing from the scope or spirit of

embodiments of the invention.

[0044] Embodiments of the invention through the GUIs from FIGS. 1 through 3F may be part of the verification mode— based on the user’s input through these fields submitted via the GUIs in these figures. For example, users may download the app or software to be installed on the mobile device 100 providing the various GUIs discussed above. The data or information entered or provided by the user may be stored in a data structure such as the data structure 402. As such, the data provided by the user may supplement or modify existing entries for the merchant. Alternative embodiments of the invention may also use the same data structure in a discovery mode.

[0045] Referring now to FIG. 4, the data structure 402 includes a data field 404 for direct data and a data field 406 for conditional data. In one embodiment, the data field 404 stores data related to direct data received from the user. In one embodiment, the data field 404 further includes sub-information or sub-fields 406-1 through 406-7 for storing data such as picture, GPS location or address information, a website address, a social media website link, an identification of an intersection, a voice recording of audio data identifying a location of the merchant, or other information. Similarly, the data structure 402 also includes the data field 406 for the conditional data fields 410-1 through 410-8, such as minimum spending, local issued non-cash payment device only, extra fees required for using a non-cash payment device, government identification required, non-cash payment device may be used during a certain hours of operation only, any product restrictions, whether contactless feature is accepted, or other conditional data.

[0046] In another embodiment, the server system may maintain the data

structure 402 in a discovery mode in which new entries may be added more than from the direct and explicit input from the user via the app. Referring now to FIG. 5, a system 500 may include mobile devices 502 from users as contributing source. In one embodiment, the contribution of information or data relating to merchant’s acceptance information comes from direct input from the mobile devices 502. In another embodiment, the system 500 may analyze indirect information from the mobile devices 502 to generate data or information needed for the data structure 402.

[0047] For example, suppose an app or software 504, as described above in

FIGS. 1 through 3F, may provide the GUIs that have been discussed above. Additionally, after obtaining privacy or explicit permission from the user, the app 504 may provide artificial intelligence features to the user even if the user fails to explicitly or directly provide the needed information in the app 504 for the merchant acceptance information. For example, suppose the user may have opened the app 504 at the location of the merchant. Flowever, before the user could finish interacting with the app 504 to provide the information, the user got distracted and never got a chance to complete the process in providing the information. In this example, embodiments of the invention enable the app 504 to intelligently provide the information that it has gathered or detected. For example, the app 504 may include a timer that may have monitored or tracked the amount of time that the user is using the app to enter the information. As the GUIs of the app 504 are designed to interact with the user easily and quickly, the app 504 may determine that after 3 minutes of no input, the app 504 may trigger its artificial intelligence (Al) algorithm by reviewing at least one of the following information available on the mobile device 502:

[0048] User’s browser history, such as browser cookies, 5 to 10 minutes before the app 504 was opened;

[0049] User’s specific search terms, such as“ATM,”“currency exchange,” etc., 5 to 10 minutes before the app 504 was opened; [0050] User’s GPS record 5 to 10 minutes before the app 504 was opened;

[0051] User’s wireless connectivity device’s activities (e.g., Wi-Fi or Bluetooth, etc.) 5 to 10 minutes before the app 504 was opened;

[0052] User’s location based on cellular signal’s triangulation 5 to 10 minutes before the app 504 was opened;

[0053] User’s stored photo storage content 5 to 10 minutes before the app 504 was opened;

[0054] User’s usages of social media or communications apps (e.g., video

conferencing or text messaging) installed on the mobile device 502 5 to 10 minutes before the app 504 was opened;

[0055] User’s phone call records to banking institutions 5 to 10 minutes before the app 504 was opened; or

[0056] User’s non-cash transactions from ATMs 5 to 10 minutes before the app 504 was opened.

[0057] In one embodiment, the app 504 may further convert the above activities, behavior or information to a data format or syntax according to the data structure 402. For example, the locational data examined or reviewed by the Al algorithm may be presented or converted to the form of a physical address.

[0058] In another embodiment, it may be possible that the mobile device 502 of the user may not have connectivity either via the cellular signal or the GPS signal. In such an example, the Al algorithm of the app 504 may monitor or track some of the activities listed above to gather information that may be needed to add a new entry according to the data structure 402. For example, the Al algorithm of the app 504 may further add the information from the monitoring or tracking to make the data structure 402 more accurate.

[0059] In other words, the Al algorithm of the app 504 may add new dimensions to the activities or behaviors of the user with the app 504 and the mobile device 502. For example, suppose the user visits an ATM where user has never been visited before and withdraws an amount that may be small (for rural areas) or in urban areas but at busy hours or close to busy hours, especially in foreign currency. Such transaction may trigger the banking institution to temporarily lock the user’s account and send a message asking for verification from the user. However, the app 504 may interpret that information as the user may be possibly need cash because a merchant nearby does not accept non-cash payment device.

[0060] As such, the app 504 may trigger its Al algorithm to transform the mobile device 502 into the discovery mode for the system 500. In another embodiment, the system 500 may also send instructions via secured channel (e.g., encryption, hashed, or tokenized) and/or application programming interface (API) to the mobile device 502 via the app 504. In such example, the instructions from the system 500 may further trigger the Al algorithm.

[0061] The system 500 may include a web server 506 to receive the data or

information from the mobile device 502. In one embodiment, the web server 506 may include at least one database 514. It is also to be understood that the databases 514 may be distributed and may be located in various locations. [0062] In another embodiment, the system 500 further includes an analysis server 508 that has access to the web server 506 and the databases 514 such that the analysis server 508 may further modify or improve the data in the databases 514 relating to the merchant acceptance information.

[0063] For example, the analysis server 508 may establish with external service providers 510 and 512 via API to receive information or data. For example, suppose the user may have used the app 504 via the mobile device 502 to enter a location information, via a map app, of the merchant. In one situation, the location information may be outdated but the user may not realize that. Upon reviewing and validating the data as discussed above, the analysis server 508 may receive the updated location information via the API from the service provider 510 of the map app if such API has already been generated. In another embodiment, the service provider 512 may a service provider of a social media platform and may also perform the similar verification process in response to data entered by the user, such as the posting of the user with the social media account with the service provider 512. The analysis server 508 may further convert the data received from the service providers 510 and 512 via the API to a proper format or structure according to that of the data structure 402 such that the information of the merchant’s acceptance of non-cash payment device is consistent and uniform.

[0064] Moreover, the system 500 may further include an administrative

configuration portal 516 to review and produce information of the merchant acceptance information. For example, the administrative configuration portal 516 may provide a GUI for the system 500 administrator to manually modify the data. In another embodiment, the administrative configuration portal 516 may also produce a report in a form of entries in a table, such as that shown in FIG. 6.

[0065] Referring to FIG. 6A, a table 600 may be an exemplary presentation or result of the data based on the input received by the user. In one embodiment, the table 600 includes the needed information for the merchant in fields labeled in 602. The table 600 may include a column 604 that designates or indicates whether the merchant accepts a non-cash payment device. The table 600 may further include a column 606 that designates or indicates the one or more conditions for accepting the non-cash payment device.

[0066] In another embodiment, the data based on the data structure 402 may be presented in a heat map 610 format in FIG. 6B where different sizes of circles represent concentrations of merchants not accepting non-cash payment devices in a certain area. For example, the acceptance information of the merchants in the table 600 may be further analyzed and presented in aggregation in the heat map 610 format or other formats. It is to be understood that the data structure 402 provides capabilities for the system or the app to extrapolate the data contained therein to enrich the data gathering. This may further enable building of more accurate and effective data set for future analysis and applications. For example, based on the data and also the number of times of users reporting a particular merchant, the system may build a report alerting an administrator, such as shown in the 516 in FIG. 5 to review possible business plans to encourage the merchant in question to use non-cash payment devices. [0067] Referring now to FIG. 7, a flow chart illustrating a computerized method for building a merchant acceptance infrastructure. At 702, a method such as via the app 504 or the system 500 provides an interactive GUI to a user on a display of a mobile device of the user. In one embodiment, the app 504 may be part of an operating system of the mobile device. In another embodiment, the app 504 may be a software product or downloaded product that may require the user to separately download and install onto the mobile device. At 704, the app 504, the system 500, or the mobile device 502 may interact with the user to obtain the acceptance information of the merchant. As illustrated in previous paragraphs, the acceptance information relates to questions such as: whether the merchant accepts a non-cash payment device and whether, if it accepts, there is any condition or restriction.

[0068] At 706, the app 504, the system 500, or the mobile device 502 may

construct a data structure based on the obtained information. In one embodiment and as previously described, the app 504 may obtain or identify information from behaviors of the user outside the app 504 but within the mobile device, e.g., user is busy capturing an image of the store but forgot to interact with the app 504, etc. As such, the app 504, the system 500, or the mobile device 502 may convert such behaviors or activities to a data format in conformance with the data structure for storage in a database.

[0069] At 708, the app 504, the system 500, or the mobile device 502 may

transmit the acceptance information stored in the database to an analysis server for additional input to the data structure. The analysis server may verify the data at 710. In one embodiment, the analysis server may provide the verified data in a tabular report in response to a request.

[0070] In another embodiment, the app 504 may provide reward incentives for receiving additional interactions from the user to increase information to be received from the user.

[0071] In a further embodiment, the steps in FIG. 7 may be distributed in nature such that there may different computing devices executing remotely. In another embodiment, the steps in FIG. 7 may not need to be implemented in a stand- alone app or software. Instead, features thereof may be part of another app, such as an app that may be tailored to travel tools, travel website, travel software, or travel apps.

[0072] FIG. 8 may be a high level illustration of a portable computing device 801 communicating with a remote computing device 841 but the application may be stored and accessed in a variety of ways. In addition, the application may be obtained in a variety of ways such as from an app store, from a web site, from a store Wi-Fi system, etc. There may be various versions of the application to take advantage of the benefits of different computing devices, different languages and different API platforms.

[0073] In one embodiment, a portable computing device 801 may be a mobile device 112 that operates using a portable power source 855 such as a battery. The portable computing device 801 may also have a display 802 which may or may not be a touch sensitive display. More specifically, the display 802 may have a capacitance sensor, for example, that may be used to provide input data to the portable computing device 801. In other embodiments, an input pad 804 such as arrows, scroll wheels, keyboards, etc., may be used to provide inputs to the portable computing device 801. In addition, the portable computing device 801 may have a microphone 806 which may accept and store verbal data, a camera 808 to accept images and a speaker 810 to communicate sounds.

[0074] The portable computing device 801 may be able to communicate with a computing device 841 or a plurality of computing devices 841 that make up a cloud of computing devices 811. The portable computing device 801 may be able to communicate in a variety of ways. In some embodiments, the communication may be wired such as through an Ethernet cable, a USB cable or RJ6 cable. In other embodiments, the communication may be wireless such as through Wi-Fi (802.11 standard), Bluetooth, cellular communication or near field communication devices. The communication may be direct to the computing device 841 or may be through a communication network 102 such as cellular service, through the Internet, through a private network, through Bluetooth, etc. FIG. 8 may be a simplified illustration of the physical elements that make up a portable computing device 801 and FIG. 9 may be a simplified illustration of the physical elements that make up a server type computing device 841.

[0075] FIG. 8 may be a sample portable computing device 801 that is physically configured according to be part of the system. The portable computing device 801 may have a processor 850 that is physically configured according to computer executable instructions. It may have a portable power supply 855 such as a battery which may be rechargeable. It may also have a sound and video module 860 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. The portable computing device 801 may also have volatile memory 865 and non-volatile memory 870. It may have GPS capabilities 880 that may be a separate circuit or may be part of the processor 850. There also may be an input/output bus 875 that shuttles data to and from the various user input devices such as the microphone 806, the camera 808 and other inputs, such as the input pad 804, the display 802, and the speakers 810, etc. It also may control of communicating with the networks, either through wireless or wired devices. Of course, this is just one embodiment of the portable computing device 801 and the number and types of portable computing devices 801 is limited only by the imagination.

[0076] As a result of the system, better information may be provided to a user at a point of sale. The information may be user specific and may be required to be over a threshold of relevance. As a result, users may make better informed decisions. The system is more than just speeding a process but uses a computing system to achieve a better outcome.

[0077] The physical elements that make up the remote computing device 841 may be further illustrated in FIG. 9. At a high level, the computing device 841 may include a digital storage such as a magnetic disk, an optical disk, flash storage, non-volatile storage, etc. Structured data may be stored in the digital storage such as in a database. The server 841 may have a processor 1000 that is physically configured according to computer executable instructions. It may also have a sound and video module 1005 which assists in displaying video and sound and may turn off when not in use to conserve power and battery life. The server 841 may also have volatile memory 1010 and non-volatile memory 1015.

[0078] The database 1025 may be stored in the memory 1010 or 1015 or may be separate. The database 1025 may also be part of a cloud of computing device 841 and may be stored in a distributed manner across a plurality of computing devices 841. There also may be an input/output bus 1020 that shuttles data to and from the various user input devices such as the microphone 806, the camera 808, the inputs such as the input pad 804, the display 802, and the speakers 810, etc. The input/output bus 1020 also may control of communicating with the networks, either through wireless or wired devices. In some embodiments, the application may be on the local computing device 801 and in other embodiments, the application may be remote 841. Of course, this is just one embodiment of the server 841 and the number and types of portable computing devices 841 is limited only by the imagination.

[0079] The user devices, computers and servers described herein may be

general purpose computers that may have, among other elements, a

microprocessor (such as from the Intel Corporation, AMD, ARM, Qualcomm, or MediaTek); volatile and non-volatile memory; one or more mass storage devices (i.e., a hard drive); various user input devices, such as a mouse, a keyboard, or a microphone; and a video display system. The user devices, computers and servers described herein may be running on any one of many operating systems including, but not limited to WINDOWS, UNIX, LINUX, MAC OS, iOS, Android, or Windows (XP, VISTA, etc.). It is contemplated, however, that any suitable operating system may be used for the present invention. The servers may be a cluster of web servers, which may each be LINUX based and supported by a load balancer that decides which of the cluster of web servers should process a request based upon the current request-load of the available server(s).

[0080] The user devices, computers and servers described herein may

communicate via networks, including the Internet, WAN, LAN, Wi-Fi, other computer networks (now known or invented in the future), and/or any

combination of the foregoing. It should be understood by those of ordinary skill in the art having the present specification, drawings, and claims before them that networks may connect the various components over any combination of wired and wireless conduits, including copper, fiber optic, microwaves, and other forms of radio frequency, electrical and/or optical communication techniques. It should also be understood that any network may be connected to any other network in a different manner. The interconnections between computers and servers in system are examples. Any device described herein may communicate with any other device via one or more networks.

[0081] The example embodiments may include additional devices and networks beyond those shown. Further, the functionality described as being performed by one device may be distributed and performed by two or more devices. Multiple devices may also be combined into a single device, which may perform the functionality of the combined devices.

[0082] The various participants and elements described herein may operate one or more computer apparatuses to facilitate the functions described herein. Any of the elements in the above-described Figures, including any servers, user devices, or databases, may use any suitable number of subsystems to facilitate the functions described herein.

[0083] Any of the software components or functions described in this application, may be implemented as software code or computer readable instructions that may be executed by at least one processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example,

conventional or object-oriented techniques.

[0084] The software code may be stored as a series of instructions or commands on a non-transitory computer readable medium, such as a random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard- drive or a floppy disk, or an optical medium such as a CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus and may be present on or within different computational apparatuses within a system or network.

[0085] It may be understood that the present invention as described above may be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art may know and appreciate other ways and/or methods to implement the present invention using hardware, software, or a combination of hardware and software.

[0086] The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

[0087] One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention. A recitation of "a", "an" or "the" is intended to mean "one or more" unless specifically indicated to the contrary. Recitation of "and/or" is intended to represent the most inclusive sense of the term unless specifically indicated to the contrary.

[0088] One or more of the elements of the present system may be claimed as means for accomplishing a particular function. Where such means-plus-function elements are used to describe certain elements of a claimed system it will be understood by those of ordinary skill in the art having the present specification, figures and claims before them, that the corresponding structure is a general purpose computer, processor, or microprocessor (as the case may be) programmed to perform the particularly recited function using functionality found in any general purpose computer without special programming and/or by implementing one or more algorithms to achieve the recited functionality. As would be understood by those of ordinary skill in the art that algorithm may be expressed within this disclosure as a mathematical formula, a flow chart, a narrative, and/or in any other manner that provides sufficient structure for those of ordinary skill in the art to implement the recited process and its equivalents. [0089] While the present disclosure may be embodied in many different forms, the drawings and discussion are presented with the understanding that the present disclosure is an exemplification of the principles of one or more inventions and is not intended to limit any one of the inventions to the

embodiments illustrated.

[0090] The present disclosure provides a solution to the long-felt need described above. In particular, the systems and methods described herein may be configured for improving verification and discovery of merchants or stores that do not accept non-cash payment devices or that do accept non-cash payments devices but differentiate them between local/national issued ones versus foreign issued ones. Further advantages and modifications of the above described system and method will readily occur to those skilled in the art. The disclosure, in its broader aspects, is therefore not limited to the specific details, representative system and methods, and illustrative examples shown and described above. Various modifications and variations can be made to the above specification without departing from the scope or spirit of the present disclosure, and it is intended that the present disclosure covers all such modifications and variations provided they come within the scope of the following claims and their

equivalents.

Claims

CLAIMS What is claimed is:

1. A computerized method for building a merchant acceptance infrastructure

comprising:

providing an interactive graphical user interface (GUI) to a user on a display of a mobile device of the user, said GUI providing one or more data fields to receive acceptance information about a non-cash payment device of a merchant from the user; interacting with the user to obtain the acceptance information of the merchant; constructing a data structure based on the obtained information, wherein the data structure is stored in a database accessible by an analysis server;

transmitting the information stored in the database to the analysis server for additional input to the data structure;

verifying by the analysis server the data received from the database; and providing a tabular report based on the verified data in response to a request.

2. The computerized method of claim 1 , wherein interacting comprises receiving input directly entered from the user to the GUI.

3. The computerized method of claim 1 , wherein interacting comprises monitoring behaviors of the user interacting with the mobile device, and further comprising converting the monitored behaviors to data in a data format according to the data structure.

4. The computerized method of claim 3, wherein monitoring comprises retrieving data already stored in the mobile device, said data already stored being associated with the behaviors of the user with the mobile device within a certain period.

5. The computerized method of claim 4, wherein retrieving data already stored in the mobile device comprises retrieving data in response to a failure to obtain the information from the user on the mobile device.

6. The computerized method of claim 1 , wherein verifying by the analysis server comprises receiving via application programming interface (API) supplemental data from a service provider, wherein the analysis server applies the supplemental data from the service provider to verify the data in the database.

7. A computerized system for building a merchant acceptance infrastructure comprising: providing an interactive graphical user interface (GUI) via a software product to a user on a display of a mobile device of the user, said GUI providing one or more data fields to receive acceptance information about a non-cash payment device of a merchant from the user;

wherein the software product interacts with the user to obtain the acceptance information of the merchant;

a web server for receiving the information from the software product, wherein the web server stores the information according to a data structure, wherein the data structure is stored in a database accessible by the web server and an analysis server; wherein the web server transmits the information stored in the database to the analysis server for additional input to the data structure;

wherein the analysis server verifies the information received from the database; and

providing a tabular report based on the verified information in response to a request.

8. The computerized system of claim 7, wherein the software product interacts comprises the software products receives input directly entered from the user to the GUI.

9. The computerized system of claim 8, wherein the software product accesses a camera associated with the mobile device of the user to receive an image as the input.

10. The computerized system of claim 8, wherein the software product accesses a microphone associated with the mobile device of the user to receive an audio data as the input.

11. The computerized system of 8, wherein the software product accesses a

communications device of the mobile device of the user to receive a hyperlink as the input.

12. The computerized system of claim 7, wherein the software product interacts comprises the software product calls a timer to determine a time when the software product is activated while not receiving any input.

13. The computerized system of claim 12, wherein the software product further comprises identifying behaviors of the user outside the software product but within the mobile device.

14. The computerized system of claim 13, wherein the software product further comprises converting the identified behavior to data in a data format according to the data structure.

15. The computerized system of claim 7, wherein the analysis server verifies comprises the analysis server receives via application programming interface (API) supplemental data from a service provider, wherein the analysis server applies the supplemental data from the service provider to verify the information in the database.

16. A non-transitory computer readable medium stored thereon computer-executable instructions embodied in a software product executed by a processor, wherein the computer-executable instructions comprising:

providing an interactive graphical user interface (GUI) via a software product to a user on a display of a mobile device of the user, said GUI providing one or more data fields to receive acceptance information about a non-cash payment device of a merchant from the user;

interacting with the user to obtain the acceptance information of the merchant, said interacting comprising identifying behaviors of the user outside the software product but within the mobile device;

converting the identified behavior to a data format according to a data structure; storing the obtained information based on the data structure, wherein the data structure is stored in a database accessible by an analysis server;

17. The computer readable medium of claim 16, wherein the software product interacts comprises the software product calls a timer to determine a time when the software product is activated while not receiving any input.

18. The computer readable medium of claim 16, wherein interacting comprises accessing a device associated with the mobile device, said device includes one of the following: a camera associated with the mobile device of the user to receive an image as the input, a microphone associated with the mobile device of the user to receive an audio data as the input, and a communications device of the mobile device of the user to receive a hyperlink as the input.

19. The computer readable medium of claim 16, wherein verifying by the analysis server verifies comprises the receiving by the analysis server via application

programming interface (API) supplemental data from a service provider.

20. The computer readable medium of claim 20, further comprising converting by the analysis server the supplemental data to a data format according to the data structure.