DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Acknowledgments
The submission (RCE and Amendment) filed on 03/05/26 is acknowledged.
Status of Claims
Claims 1-15 and 18-22 are pending.
In the Amendment filed (with RCE) on 03/05/26, claims 1, 8 and 15 were amended, claims 16 and 17 were cancelled, and claims 21 and 22 were added. (Note for clarification of the record: the changes to the claims made in the Amendment filed on 03/05/26 include the changes to the claims made in the Amendment filed on 02/13/26 as well as further changes.)
Claims 1-15 and 18-22 are rejected.
Response to Arguments
Regarding the rejection under 35 U.S.C. 101
Applicant's arguments have been fully considered but are not persuasive.
The Office responds to Applicant's arguments below. In the discussion below, page numbers refer to Applicant's instant Response unless otherwise indicated.
Initially, the Office notes that the bulk of Applicant's arguments are verbatim repetition of Applicant's arguments presented in the Amendment filed on 10/07/25 (hereafter, "previous arguments"). The portion of Applicant's instant arguments that are newly presented (i.e., additions to the previous arguments) are as follows:
p. 9, second paragraph of the arguments pertaining to 35 U.S.C. 101, and the following sentence, replace a set of 3 different paragraphs in the previous arguments (at pp. 10-11 of the Amendment filed on 10/07/25)
p. 10, last paragraph has been added
Also:
at p. 10, first full paragraph, penultimate line, "particular data" (in previous arguments) has been changed to "particular transaction data"
at page 11, third paragraph, penultimate sentence, "leveraging machine learning by" has been added
While Applicant's arguments in the Amendment filed on 10/07/25 were responded to in the Response to Arguments in the Final Office Action issued on 12/18/25, Applicant does not acknowledge or substantively address the content of this response by the Office.
We turn now to Applicant's arguments.
As for Step 2A, prong 1, Applicant (newly) argues:
With respect to the assertion that the claim recites an abstract idea, Applicant submits that the claims, at best, involve an exception and do not recite an exception. In this regard, the MPEP states that "Examiners should ... be careful to distinguish claims that recite an exception (which require further eligibility analysis) and claims that merely involve an exception (which are eligible and do not require further eligibility analysis)." MPEP § 2106.04(II)(A)(1) (emphasis in original). The present claims merely involve an exception, instead of reciting an exception. The claims, when taken as a whole, recite features directed to leveraging machine learning by executing a clustering algorithm to generate data clusters that are used, in conjunction with user and location information, to generate an interactive graphical user interface including interactive icons having a displayed shape generated based on particular data. While the claim may involve an abstract idea, when considered as a whole, the claims do not recite an abstract idea. (Response, p. 9; underlining added)
In response, the Office notes that, as per the rejection, the independent claims recite abstract idea elements such as receiving transaction data; extracting user information and location information; executing a clustering algorithm to cluster transactions; generating a mapping, including an icon identifying a transaction, wherein a shape of the icon is based on payment device data; transmitting the mapping to a user for display; receiving user input selecting the icon; responsive to receiving the user input, generating transaction details; and transmitting the transaction details to the user for display overlaying the mapping. The independent claims do not recite "machine learning." As noted, the clustering algorithm is part of the abstract idea. The interactive interface and the interactivity of the icons are additional elements. The other additional elements of the independent claims (not mentioned in Applicant's argument above) are a computing device, user computing device, display, user interface, pop-up interface, computing platform comprising at least one processor, a communication interface, and a memory, and one or more non-transitory computer-readable media. The additional elements are recited at a high level of generality and not described, and are used in their conventional capacity (generic computer elements), and accordingly merely function to apply the abstract idea. As such, the independent claims recite, not merely involve, an abstract idea, namely, the idea of mitigating transaction fraud by facilitating transaction fraud reporting using an interactive map (see also Abstract, and specification 0002, 0004, 0007). This abstract idea falls under "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions."
As for Step 2A, prong 2, Applicant (as per previous arguments) argues:
The claims clearly recite a practical application of any alleged abstract idea. For example, claim 1 recites multiple, specific, detailed, unique steps performed by or at particular devices to execute a clustering algorithm to generate data clusters that are used, in conjunction with user and location information, to generate an interactive graphical user interface including interactive icons having a particular shape determined based on particular transaction data. The claims are necessarily rooted in technology.
The features of the claims clearly impose a meaningful limit on the judicial exception such that the claim is "more than a drafting effort designed to monopolize the judicial exception." See 2019 Guidance at 13-14. In other words, claim 1 does not monopolize every possible arrangement for "mitigating transaction fraud by facilitating transaction fraud reporting using an interactive map" or any alleged abstract idea, but instead is limited to a practical application of doing so, including particular steps relying on particular devices and performed in a particular order.
…1
As discussed in the October 2019 Update, "the limitations containing the judicial exception, as well as the additional elements in the claim besides the judicial exception need to be evaluated together to determine whether the claim integrates the judicial exception into a practical application. The additional limitations should not be evaluated in a vacuum..." October 2019 Update at p. 12. As discussed above, "taking into consideration all the claim limitations and how those limitations interact and impact each other," as required in the October 2019 update when evaluating whether the exception is integrated into a practical application, it is clear that the claims integrate any alleged abstract idea into a practical application. (Emphasis added). Therefore, claim 1 is not "directed to" a judicial exception, and thus is patent eligible. See 2019 Guidance at 13. (Response, pp. 10-11; underlining added in first paragraph above)
In response, the Office notes that Applicant cites the same claimed subject matter (indicated above by underlining) as was cited with respect to Step 2A, prong 1 (see underlined portion of Applicant's argument with respect to Step 2A, prong 1, above). As stated above, this subject matter is for the most part abstract idea content (e.g., it is used to generate the map), except for the interactivity and generic computer limitations (e.g., computing device, display, user interface, pop-up, processor, etc.), recited at a high level of generality and used in their conventional capacity, which do not reflect an improvement in computer functioning/technology. As such, the claims amount to no more than mere instructions to apply the exception using generic computer elements. To the extent to which the claim recitations are specific, detailed and unique, they reflect the narrowing of the abstract idea. As for "rooted in technology," again, the claims do not recite any technology, aside from the indicated generic computer elements, and hence do not recite any improvement in computer functioning/ technology.
Further, the alleged 'meaningful limit' / lack of 'monopolization', and 'particular steps' and 'particular order', asserted by Applicant, merely reflect the narrowing of the abstract idea, while the 'particular devices' are merely generic computer elements, recited at a high level of generality, and used in their ordinary capacity/functionality, such that the claims when considered as a whole amount to no more than mere instructions to apply the exception using generic computer elements.
Finally, the Office notes that all of the claim limitations were evaluated together. That evaluation found that, when considered as a whole, no synergistic, emergent, or the like aspects, elements, features, etc. are seen beyond the sum of the individual elements of the claims. Indeed, Applicant does not present any such synergistic features or the like in support of Applicant's argument. Hence, this part of the argument is devoid of any support based on the facts of Applicant's particular claims, and therefore this part of the argument amounts to a conclusory argument.
With respect to Step 2A, prong 2, Applicant further (newly) argues:
The Office Action dismisses the improvements described in the specification and provided by the steps of the claims. By brushing aside the improvements described in the specification and the manner in which the claims describe a practical application that provides such improvements, the Office makes the same error as the appeal panel in Ex Parte Desjardins. There, the Director overturned the panel's decision that a claim directed to artificial intelligence was ineligible "because the panel essentially equated any machine learning with an unpatentable 'algorithm' and the remaining additional elements as 'generic computer components,' without adequate explanation." Ex Parte Desjardins, Appeal No. 2024-000567, p. 9 (ARP Sept. 26, 2025) (precedential). Here, the Office is similarly overlooking the value of the machine learning aspect recited and merely stating that the claims "do not recite any technology" and "amount to no more than mere instructions to apply the exception using generic computer elements." This disregard for the specific functionality and improvements offered by the features of the claims is exactly the type of action the Director cautioned against in Desjardins. Desjardins at 9 ("Examiners and panels should not evaluate claims at such a high level of generality"). (Response, p. 10; underlining added)
In response, first, the Office notes that the specification does not explicitly mention any "improvement" or the prior art or conventional techniques. The closest the specification comes to such topics appears to be at paragraphs 2, 4 and 17, which read as follows:
[2] Quickly identifying potential unauthorized activity in both event processing and device or application logins is critical for users to mitigate impact of fraudulent activity. However, viewing event processing data and/or login data in text form and/or list form might not be informative enough for a user to determine whether a transaction is fraudulent. Accordingly, it would be advantageous to dynamically generate an interactive mapping interface to provide a visual representation of event processing and/or login data for users to identify potential unauthorized activity.
[4] Aspects of the disclosure provide effective, efficient, scalable, and convenient technical solutions that address and overcome the technical issues associated dynamically generating graphical displays of user event processing and/or login data to identify and report fraudulent activity.
[17] As discussed above, quickly evaluating login occurrences and/or processed events to identify potential unauthorized activity is critical for users to protect their data, accounts, and the like. Accordingly, arrangements described herein provide dynamic generation of interactive mapping interfaces to provide a visualization of user events and login attempts. Users may view different data layers to see different types of transactions, types of events, via a map view to visualize a physical location of a transaction or login attempt. Accordingly, if a user does not recognize a transaction or login attempt, the user may select an icon associated with the event to view additional transaction details via an additional user interface. In some examples, the additional user interface may include a selectable option to report the transaction as potential fraudulent. In some examples, selection of that option may cause initiation of a communication session between a fraud reporting computing system and a user computing device.
However, the subject matter set forth above at paragraphs 2, 4 and 17 is taught by the prior art, as per the references applied against the claims and the other references cited but not applied against the claims.
In addition, Applicant does not specify or offer any indication of what "the improvements … provided by the steps of the claims" are.
Accordingly, it is not clear what "improvements" Applicant is referring to in the argument set forth above.
Since, as stated above and set forth in the rejection hereinbelow, the prior art teaches the claimed subject matter, no improvement is seen in the claims.
Second, the Office notes that the instant claims are not comparable to Desjardins. Again, the instant independent claims do not recite "machine learning," let alone training machine learning as claimed in Desjardins. Again, the recited clustering is part of the abstract idea, and does not represent an improvement in computer functioning/ technology.
As for Step 2B, Applicant (as per previous arguments) argues:
When the language of each claim feature is considered, both alone and in combination, it is clear that the claims recite significantly more than merely "mitigating transaction fraud by facilitating transaction fraud reporting using interactive map GUIs," or any alleged abstract idea. See MPEP §2106.05(a) (noting that "it is critical that examiners look at the claim 'as a whole,' in other words, the claim should be evaluated 'as an ordered combination, without ignoring the requirements of the individual steps'"). Further, the claim features are necessarily rooted in computer technology, and include particular processes and devices for executing a clustering algorithm to generate data clusters that are used, in conjunction with user and location information, to generate an interactive graphical user interface including interactive icons having a shape generated based on particular data. Clearly, the features recited in the claims are significantly more than merely "mitigating transaction fraud by facilitating transaction fraud reporting using interactive map GUIs," or any alleged abstract idea. (Response, p. 11; underlining added)
In response, the Office notes that Applicant merely cites again the same subject matter (indicated above by underlining) and asserts in conclusory fashion that this amounts to significantly more than the abstract idea. The cited subject matter has already been addressed above. Namely, the cited "particular processes" merely reflect a narrowing of the abstract idea, and "particular … devices" merely reflect generic computer elements, recited at a high level of generality, and used in their ordinary capacity/functionality, such that, as discussed above with respect to step 2A, prong 2, the claims amount to no more than mere instructions to apply the exception using generic computer elements.
Finally, as per the rejection, the additional elements were found to amount merely to instructions to apply the exception using generic computer elements and, as such, they cannot provide an inventive concept or significantly more under step 2B, as the courts have indicated. MPEP 2106.05.I.A. (i., iv.)
Regarding the rejections under 35 U.S.C. 103
Applicant's arguments have been fully considered but are moot in view of the new combinations of references used in the instant rejections.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15 and 18-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-15 and 18-22 are directed to a computing platform, method, or non-transitory computer-readable media, which are/is one of the statutory categories of invention. (Step 1: YES)
Claims 1, 8 and 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite a computing platform, method, or non-transitory computer-readable media for mitigating transaction fraud by facilitating transaction fraud reporting using an interactive map (see also Abstract, and specification 0002, 0004, 0007).
For claims 1, 8 and 15 (claim 1 being deemed representative), the limitations (indicated below in bold) of:
receive transaction data including a plurality of transactions executed by a plurality of users;
extract, from the transaction data, user information and location information for each transaction of the plurality of transactions;
execute, based on the extracted user information, a clustering algorithm to cluster transactions associated with particular users;
generate, based on the user information, the clustered transactions, and the location information, an interactive mapping interface, wherein the interactive mapping interface includes an interactive icon identifying at least one transaction of the plurality of transactions executed by a user and a location of the transaction, wherein a displayed shape of the interactive icon is based on payment device data in the at least one transaction;
transmit the interactive mapping interface to a user computing device, wherein transmitting the interactive mapping interface to the user computing device causes the user computing device to display the interactive mapping interface on a display of the user computing device;
receive, from the user computing device and via the interactive mapping interface, user input selecting the interactive icon identifying the at least one transaction;
responsive to receiving the user input, generate a transaction details user interface including additional details of the at least one transaction; and
transmit the transaction details user interface to the user computing device, wherein transmitting the transaction details user interface to the user computing device causes the user computing device to display the transaction details user interface on the display of the user computing device and as a pop-up interface overlaying the interactive mapping interface.
as drafted, constitute a process that, under the broadest reasonable interpretation, covers "certain methods of organizing human activity," specifically, "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components. The Examiner notes that "fundamental economic practices" or "fundamental economic principles" describe concepts relating to the economy and commerce, including hedging, insurance, and mitigating risks, and "commercial interactions" or "legal interactions" include agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. MPEP 2106.04(a)(2)II.A.,B. If a claim limitation, under its broadest reasonable interpretation, covers "fundamental economic practices or principles" and/or "commercial or legal interactions," but for recitation of generic computer components, then it falls within the "certain methods of organizing human activity" grouping of abstract ideas. Accordingly, claims 1, 8 and 15 recite an abstract idea. (Step 2A - Prong 1: YES. The claims recite an abstract idea.)
This judicial exception is not integrated into a practical application. Claims 1, 8 and 15 recite the additional elements of an interactive [mapping] interface, the interactive [mapping] interface includes an interactive [icon], a user computing device, the interactive [mapping] interface on a display of the user computing device, the interactive [icon], a [transaction details] user interface, the [transaction details] user interface on the display of the user computing device, a pop-up interface (the foregoing recited by claims 1, 8 and 15), a computing platform comprising at least one processor, a communication interface, and a memory storing instructions (the foregoing recited by claim 1), a computing platform having at least one processor and memory (the foregoing recited by claim 8), and one or more non-transitory computer-readable media storing instructions, a computing platform comprising at least one processor, memory, and a communication interface (the foregoing recited by claim 15), that implement the abstract idea. These additional elements are not described by the applicant and they are recited at a high level of generality (i.e., one or more generic computer elements performing generic computer functions), such that they amount to no more than mere instructions to apply the exception using generic computer elements. Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. (Step 2A - prong 2: NO. The additional elements do not integrate the abstract idea into a practical application.)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of an interactive [mapping] interface, the interactive [mapping] interface includes an interactive [icon], a user computing device, the interactive [mapping] interface on a display of the user computing device, the interactive [icon], a [transaction details] user interface, the [transaction details] user interface on the display of the user computing device, a pop-up interface (the foregoing recited by claims 1, 8 and 15), a computing platform comprising at least one processor, a communication interface, and a memory storing instructions (the foregoing recited by claim 1), a computing platform having at least one processor and memory (the foregoing recited by claim 8), and one or more non-transitory computer-readable media storing instructions, a computing platform comprising at least one processor, memory, and a communication interface (the foregoing recited by claim 15), to perform the noted steps amount to no more than mere instructions to apply the exception using generic computer elements. Mere instructions to apply an exception using generic computer elements cannot provide an inventive concept ("significantly more"). Accordingly, even in combination, these additional elements do not provide significantly more. As such, claims 1, 8 and 15 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more.)
Dependent claims 2-7, 9-14 and 18-22 are similarly rejected because they further define/narrow the abstract idea of independent claims 1, 8 and 15 as discussed above, and/or do not integrate the abstract idea into a practical application or provide an inventive concept such as would render the claims eligible, whether each is considered individually or as an ordered combination.
As for further defining/narrowing the abstract idea:
Dependent claims 2-7, 9-14 and 18-22 merely describe data layers (included in an interface) (claims 2, 9), data layers displayed based on a user selection (claims 3, 10), a selectable option to report fraud (claims 4, 11, 18), receiving user input to select the selectable option to report fraud (claims 5, 12, 19); generating and transmitting an instruction to initiate a communication session (claims 5, 12, 19); receiving data in real-time (claims 6 and 13); extracting and processing data (claims 7, 14, 20); determining information (claim 21); and generating icons, wherein a color of each icon identifies a feature.
As for additional elements:
Claims 2 and 9 recite “the interactive [mapping] interface.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 4, 11 and 18 recite “the [transaction details] user interface.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 5, 12 and 19 recite “a fraud reporting system and the user computing device,” with respect to a communication initiated therebetween, initiated by the former in response to an instruction transmitted thereto (claims 5, 12 and 19), and “instructions that, when executed, cause the computing platform to” perform the operations (claims 5 and 19). This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 7, 14 and 20 recite “using a machine learning model.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 21 recites “the user computing device.” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claim 22 recites “the interactive [mapping] interface"; "[a plurality of] interactive [icons]"; and "[each] interactive [icon].” This recitation is at a high level of generality such that it amounts to no more than mere instructions to apply the exception using a generic computer element. Even in combination these additional elements do not integrate the abstract idea into a practical application and do not amount to significantly more than the abstract idea itself.
Claims 3, 6, 10 and 13 do not recite any additional elements, and accordingly, for the reasons provided above with respect to the independent claims, are not patent eligible.
Therefore, dependent claims 2-7, 9-14 and 18-22 are not patent eligible.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 6-10, 13-15 and 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over Narayanaswami et al. (U.S. Patent Application Publication No. 2010/0082454 A1), hereafter Narayanaswami, in view of Somashekar et al. (U.S. Patent Application Publication No. 2013/0325681 A1), hereafter Somashekar, and further in view of Colon et al. (U.S. Patent Application Publication No. 2013/0268340 A1), hereafter Colon.
Regarding Claims 1, 8 and 15
Narayanaswami teaches:
(claim 1) A computing platform, comprising: at least one processor; a communication interface communicatively coupled to the at least one processor; and a memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to: (Fig. 7, 0098-0105, 0032-0033)
(claim 8) a computing platform, the computing platform having at least one processor and memory (Fig. 7, 0098-0105, 0032-0033)
(claim 15) One or more non-transitory computer-readable media storing instructions that, when executed by a computing platform comprising at least one processor, memory, and a communication interface, cause the computing platform to: (0100-0105, Fig. 8)
receive transaction data including a plurality of transactions executed by a plurality of users; (0026 electronic receipts (per 0023 in large number) are received by receipt vault 105, which per 0032 may be part of processing device 107/server connected to processing device 107, hence the receipts are received by processing device 107 (computing platform); per Fig. 3 and 0045 “electronic receipt may contain information such as the vendor name, address and phone number, the customerid, geocoding information about the vendor's location, the type of receipt (customer receipt, gift receipt, etc.) and information about the receipt's visibility (public, private or limited to a set of people) (transaction data))
extract, from the transaction data, user information and location information for each transaction of the plurality of transactions; (Per Fig. 3 and 0045 “electronic receipt may contain information such as the vendor name, address and phone number, the customerid, geocoding information about the vendor's location, the type of receipt (customer receipt, gift receipt, etc.) and information about the receipt's visibility (public, private or limited to a set of people) (transaction data).” Per 0051 location information is derived (extracted) from electronic receipt. Per 0036 (“information from the electronic receipt … may be displayed with the map to allow a user to view information from the electronic receipt with respect to the map. For example, information from the electronic receipt may be simultaneously displayed with the map and may be displayed beside the map or superimposed on a part of the map.”) and 0079 (“accessing (530) the electronic receipt in the storage device to generate a display screen which displays a map corresponding to the information included in the electronic receipt”), the information included in the electronic receipt (which per Fig. 3 and 0045 includes user information and location information) is included in the map and is used to generate the map, which necessarily involves using the information of the electronic receipt, hence extracting the information from the receipt. Again, per 0037, 0041 the generated map shows the user’s own transactions; in order for this to be performed, the user’s information (customerid or other user information) must have been used, hence must have been taken (extracted) from the electronic receipts (transaction data).)
…
generate, based on the user information … and the location information, an interactive mapping interface (Fig. 2A, 211), (0033-0036, 0056, 0058)
wherein the interactive mapping interface includes an interactive icon (marker) identifying at least one transaction of the plurality of transactions executed by a user and a location of the transaction …; (0058)
transmit the interactive mapping interface to a user computing device, wherein transmitting the interactive mapping interface to the user computing device causes the user computing device to display the interactive mapping interface on a display of the user computing device; (0033 “The processing device 107 may also store a purchase history viewing tool (e.g., a program such as a software application stored on the hard drive of a computer) which is executable for handling and viewing the data (e.g., electronic receipts) stored in the receipt vault 105. A display device 111 (e.g., light-emitting diode (LED) display, liquid crystal display (LCD), cathode ray tube (CRT) display, etc.) may also be connected (e.g., wired or wirelessly connected) to the processing device 107. The processing device 107 may include a processor (e.g., central processing unit (CPU) which executes the instructions of the purchase history viewing tool to generate a graphical user interface (GUI) and cause the display device 111 to display the GUI. ”, see also 0035, 0056; regarding transmit the interactive mapping interface to a user computing device: the GUI is transmitted by processing device 107 (computing platform) to display device 111 (user computing device) via network 103, as shown in Fig. 1, or by wired connection, as per 0033)
receive, from the user computing device and via the interactive mapping interface, user input selecting the interactive icon identifying the at least one transaction; (0058 “The user could then use the input device 109 to move a cursor over the marker (e.g., “pin”) which may cause a receipt information box 213 to be displayed on the screen (e.g., superimposed on the map 211, displayed beside the map 211, etc.), the box 213 including information associated with the electronic receipt associated with that marker.”)
responsive to receiving the user input, generate a transaction details user interface (Fig. 2A, 213) including additional details of the at least one transaction; and (0058 “The user could then use the input device 109 to move a cursor over the marker (e.g., “pin”) which may cause a receipt information box 213 to be displayed on the screen (e.g., superimposed on the map 211, displayed beside the map 211, etc.), the box 213 including information associated with the electronic receipt associated with that marker.”)
transmit the transaction details user interface to the user computing device, wherein transmitting the transaction details user interface to the user computing device causes the user computing device to display the transaction details user interface on the display of the user computing device and as a pop-up interface overlaying (superimposed on) the interactive mapping interface. (Fig. 2A, 211, 213, 0058 “The user could then use the input device 109 to move a cursor over the marker (e.g., “pin”) which may cause a receipt information box 213 to be displayed on the screen (e.g., superimposed on the map 211, displayed beside the map 211, etc.), the box 213 including information associated with the electronic receipt associated with that marker.”)
Narayanaswami does not explicitly disclose but Somashekar teaches:
execute, based on the extracted user information, a clustering algorithm to cluster transactions associated with particular users; (0017, 0060, 0164, Fig. 20, 0200, Fig. 64 generating a map of users' financial transaction data (transactions, offers, etc.); relatedly 0184-0187, Fig. 28A teaches using machine learning to extract geolocation information regarding transactions of a user; 0255 clustering may be used to generate the information used to generate the map as described in 0017, 0164, 0184-0187, 0200; 0273, Fig. 74, esp. 7110, also teaches the clustering of transactions associated with particular users ("Here the output is sorted into a number of data sets including a data set of transactions by John Doe, a data set of transactions by Jane Doe, a data of transactions by Bob Smith, and the like."), and per 0274, the clustered transactions are used to generate the graph ("presented to the customer in any of a variety of manners including on … an online graphical user interface associated with the user's financial account"))
… the clustered transactions …; (0017, 0060, 0164, Fig. 20, 0200, Fig. 64 generating a map of users' financial transaction data (transactions, offers, etc.); relatedly 0184-0187, Fig. 28A teaches using machine learning to extract geolocation information regarding transactions of a user; 0255 clustering may be used to generate the information used to generate the map as described in 0017, 0164, 0184-0187, 0200; 0273, Fig. 74, esp. 7110, also teaches the clustering of transactions associated with particular users ("Here the output is sorted into a number of data sets including a data set of transactions by John Doe, a data set of transactions by Jane Doe, a data of transactions by Bob Smith, and the like."), and per 0274, the clustered transactions are used to generate the graph ("presented to the customer in any of a variety of manners including on … an online graphical user interface associated with the user's financial account"))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified Narayanaswami's interactive purchase history map UI, by incorporating therein these teachings of Somashekar regarding clustering transaction data for display on a map, because it allows for efficiently determining transaction data and conveniently displaying it, in accordance with Narayanaswami’s spirit/goals of making it easier for users to find out about their purchases including the locations thereof, see Narayanaswami, 0005, 0039-0041, 0058 (providing a transactions details UI as part of the map UI), 0084-0086 (e.g., 0085 “an easy-to-use visual tool to monitor purchasing history patterns. … and flag suspicious activity”; 0086 "allow a parent to quickly (e.g., instantly) receive and monitor credit card spending by a child. Receipts are viewable by geography, allowing easy monitoring of credit card spending in different locations.").
Narayanaswami in view of Somashekar does not explicitly disclose but Colon teaches:
… wherein a displayed shape of the interactive icon (indicator) is based on payment device data in the at least one transaction; (0031 indicator (e.g., shape) on map indicates transaction and its location; 0033 characteristic of indicator can be shape, color, size, etc., and can be modified based on any of various parameters such as: 0034 characteristic can be based on transaction status; 0035 characteristic can be based on transaction amount or on transaction frequency; 0036 characteristic can be based on transaction date/time; 0037 characteristic can be based on transaction type, or discount amount; 0038 characteristic can be based on distance of transaction location to account holder address; under broadest reasonable interpretation, the foregoing transaction parameters are "payment device data" because they are transaction data associated with the payment device, and also because one of ordinary skill in the art understands that these transaction parameters, which constitute transaction history and fraud factors, may be deemed to fall within the definition of "payment device data," as taught, e.g., by (1) Bohatka, 0133 ("payment device data (e.g., expiry, payment device ID, card type, fraud data, activity history data, token data)" and by (2) security.stackexchange.com, pp. 1-2 ("I installed an NFC reader on my android and scanned each of my bank cards to see what they would reveal through their contactless feature (NFC). … I was surprised to find though my Mastercard credit card revealed a transaction history with the charged amount and the date and time of the transaction, I tried this out with another card and found the same. … What is the benefit of storing this transaction history on the card itself? … Considering some card issuers use transaction history as part of their security verification process leaking the info isn't ideal. … Transaction history is I believe part of the EMV standard. Visa disable it by default whilst Mastercard don't. … What is the benefit of storing this transaction history on the card itself? One possibility would be with something like TFL in london. You can tap into and out of the transport network with a contactless bank card. TFL have inspectors on random trains/buses that ask you to present your payment method - for contactless cards they scan them with a reader. For cards offering transaction history they could verify immediately whether the card was tapped in. Without this they have to compare inspected card logs against transaction logs when they are processed at end of day - meanwhile if the card was fake/stolen the holder is long gone.")
Note Colon (0059, see 0058-0060) also teaches display the transaction details user interface on the display of the user computing device and as a pop-up interface overlaying the interactive mapping interface.
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, by incorporating therein these teachings of Colon regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, because it serves to provide additional information about the transaction in a compact/efficient manner, so as to minimize screen clutter while facilitating user review of the transaction to check for fraud, etc., see Colon, 0002-0005, see Narayanaswami, 0005, 0039-0041, 0084-0086 (e.g., 0085 “an easy-to-use visual tool to monitor purchasing history patterns. … and flag suspicious activity”; 0086 "allow a parent to quickly (e.g., instantly) receive and monitor credit card spending by a child. Receipts are viewable by geography, allowing easy monitoring of credit card spending in different locations.").
Regarding Claims 2 and 9
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claims 1, 8 and 15 as set forth above. Narayanaswami further teaches:
wherein the interactive mapping interface includes a plurality of data layers. (Fig. 2E, 0076 the “seven (7) electronic receipts, as indicated by the electronic receipt information boxes 253 a-253 g displayed on the map 251 of display screen 250” constitute a plurality of data layers)
Regarding Claims 3 and 10
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claims 1, 8 and 15 and intervening claims 2 and 9 as set forth above. Narayanaswami further teaches:
wherein each data layer of the plurality of data layers is displayed based on user selection of a respective data layer. (Fig. 2E, 2F, 0076-0078 user can filter the displayed layers so as to retain (display) only those layers that are not filtered out by the user’s filtering selection, i.e., only those layers that are selected by the user’s filtering selection, e.g., as shown in Fig. 2F the user has filtered/selected to retain only layer (transaction) 253 g among the seven layers (transactions); note the claim language (based on user selection of a respective data layer) does not require that the selection be unmediated by any intervening step, mechanism, or the like, such as filtering)
Regarding Claims 6 and 13
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claims 1 and 8 as set forth above. Narayanaswami further teaches:
wherein the transaction data is received in real-time. (0037 “On completion of a sale (e.g., shortly before or shortly after the customer pays for the items purchased and sale is completed), a vendor may provide the customer with access to an electronic receipt, which the customer can store in the electronic receipt vault 105. The customer can then use the GUI (e.g., view the display screen 210-260) displayed on the display device 111 and the input device 109 to manipulate (e.g., handle, view, configure, etc.) the data stored in the electronic receipt vault 105 to display receipts on a map based on selection criteria (e.g., user-selected criteria) and filtering (e.g., user-selected filtering) of displayed receipts.”; 0068 “Receipts may be optionally be updated with live information before they are displayed in the electronic receipt information box 103. The receipt viewer (e.g., purchase history viewing tool) may optionally contact the vendor database 102 to determine if any new information is available on the item and update the information displayed in the electronic receipt information box 103 accordingly.”)
Regarding Claims 7, 14 and 20
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claims 1, 8 and 15 as set forth above. Somashekar further teaches:
wherein extracting, from the transaction data, user information and location information for each transaction of the plurality of transactions includes processing the transaction data using a machine learning model. (0266-0271 machine learning is used to determine user habits (user information) and geographic locations (location information) from transaction data (note the "customer data sets 7008" inputted in the machine learning model (0269) are in fact transaction data (see 0266, "customer data sets 7008 may be derived from a plurality of one or more financial transaction data sets 7002"))
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, and as further modified by Colon's teachings regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, by incorporating these further teachings of Somashekar regarding using machine learning to determine user data and location data from transaction data, because it would improve the accuracy and efficiency of the data determination performed by Narayanaswami. MPEP 2143.I.C.,D.
Regarding Claim 21
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claim 1 as set forth above. Colon further teaches:
wherein the location information is determined from an internet protocol address of the user computing device. (0029 "processing module 106 may process the point of sale location information, IP address of system or the like to determine an address of the transaction location or geographical coordinates of the transaction location.")
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, and as further modified by Colon's teachings regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, by incorporating these further teachings of Colon regarding determining the location of a transaction from the IP address of a purchaser's device, because it is a known way of determining location and as such could be used by Narayanaswami to determine transaction location either in addition to (e.g., for confirmation purposes) or instead of the ways in which Narayanaswami teaches determining transaction location, MPEP 2143.I.A.,B.
Regarding Claim 22
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claim 1 as set forth above. Narayanaswami further teaches:
wherein generating the interactive mapping interface includes generating a plurality of interactive icons (markers) identifying each transaction of the plurality of transactions, …. (0033-0037, 0052-0058, Figs. 2A-2F, purchase history, i.e., plurality of transactions, is displayed on generated interactive map, via interactive "markers" (0058), where each marker represents a transaction; per 0055, user can filter the purchase history to be displayed, to show subsets of transactions, various examples of which are described at 0059-0064 and 0076-0078; the fact that a plurality of transactions/markers is generated is highlighted in 0061 ("the map 211 would include a marker indicating a precise location (e.g., vendor location) for every electronic receipt which is associated with that zip code") and Figs. 2C, 233 (two receipts/markers/transactions) and 2D, 243 (two receipts/markers/transactions))
Colon further teaches:
wherein generating the interactive mapping interface includes generating a plurality of interactive icons identifying each transaction of the plurality of transactions, and wherein a color of each interactive icon (indicator) identifies a feature of a respective transaction of the plurality of transactions. (0031 "Mapping module 108 may be a mapping tool that provides computer represented maps (hereinafter used as “maps”). … mapping module 108 may identify geographic locations corresponding to the transaction locations on the map. Using the transaction location, mapping module 10$ [sic, 108] geographically map [sic, maps] indicators representing the financial transactions"; 0033 characteristic of indicator can be shape, color, size, etc., and can be modified based on (i.e., can identify) any of various parameters such as; 0034 color of indicator identifies transaction status, e.g., red = unfinished, green = completed; 0035 color of indicator identifies transaction amount, e.g., exceeding a threshold or not; 0036 color of indicator identifies transaction date/time; 0037 color of indicator identifies transaction type, or discount amount; 0038 color of indicator identifies transaction type, or discount amount; 0038 characteristic (e.g., color) of indicator identifies distance of transaction location to account holder address; see 0031-0033 for background/context of 0034-0038)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, and as further modified by Colon's teachings regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, by incorporating these further teachings of Colon regarding using the color of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, because it serves to provide still additional information about the transaction in a compact/efficient manner, so as to minimize screen clutter while facilitating user review of the transaction to check for fraud, etc., see Colon, 0002-0005, see Narayanaswami, 0005, 0039-0041, 0084-0086 (e.g., 0085 “an easy-to-use visual tool to monitor purchasing history patterns. … and flag suspicious activity”; 0086 "allow a parent to quickly (e.g., instantly) receive and monitor credit card spending by a child. Receipts are viewable by geography, allowing easy monitoring of credit card spending in different locations.").
Claims 4, 5, 11, 12, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Narayanaswami et al. (U.S. Patent Application Publication No. 2010/0082454 A1), hereafter Narayanaswami, in view of Somashekar et al. (U.S. Patent Application Publication No. 2013/0325681 A1), hereafter Somashekar, further in view of Colon et al. (U.S. Patent Application Publication No. 2013/0268340 A1), hereafter Colon, and further in view of Pawar et al. (U.S. Patent Application Publication No. 2025/0014041 A1), hereafter Pawar.
Regarding Claims 4, 11 and 18
Narayanaswami in view of Somashekar and Colon teaches the limitations of base claims 1, 8 and 15 as set forth above. Narayanaswami in view of Somashekar and Colon does not explicitly disclose but Pawar teaches:
wherein the transaction details user interface includes a selectable option to report the at least one transaction as potentially fraudulent. (0020 “In some implementations, when the user device accesses the account, the corresponding channel may support one or more user interfaces to display information related to posted and/or pending transactions that have been charged to the account associated with the user, and the one or more user interfaces may include options to report a potential problem or incident with a transaction that may be fraudulent or disputed. … For example, in some implementations, the user interface used to report the potential incident may correspond to a transaction details screen that indicates an amount, a merchant, a date, and/or other information associated with a transaction and provides an option to report a problem with the transaction.”; 0028 “the user enters the intake workflow through a transaction details screen, which may include information such as an amount, a posting date, a merchant name, a merchant address, a website link, and/or an option to report or request help with a transaction”)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, and as further modified by Colon's teachings regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, by incorporating therein these teachings of Pawar regarding a transaction details UI including a selectable option to report a transaction as potentially fraudulent, because Narayanaswami teaches using the interactive purchase history map UI to report fraud (0084-0085 “an easy-to-use visual tool to monitor purchasing history patterns. … and flag suspicious activity”) and teaches providing a transactions details UI (as part of the map UI) (0058) but does not provide extensive detail regarding the fraud reporting functionality, while Pawar teaches integrating the fraud reporting functionality into the UI, such as to make it easier/more convenient for the user to report fraud via the (transaction details UI of the) interactive purchase history map UI itself, and as such the proposed combination would increase fraud mitigation and improve Narayanaswami, while at the same time building on Narayanaswami’s teachings in accordance with Narayanaswami’s spirit/goals of making it easier for users to find out about their purchases including the locations thereof, for the sake, inter alia, of mitigating fraud, see Narayanaswami, 0005, 0039-0041, 0084-0085, MPEP 2143.I.C.,D.
Regarding Claims 5, 12 and 19
Narayanaswami in view of Somashekar, Colon and Pawar teaches the limitations of base claims 1, 8 and 15 and intervening claims 4, 11 and 18 as set forth above. Pawar further teaches:
further including instructions that, when executed, cause the computing platform to: (claim 15 “one or more instructions that, when executed by one or more processors of an intake system, cause the intake system to:”, see also claim 1)
receive additional user input selecting the selectable option to report the at least one transaction as potentially fraudulent; (Fig. 1, 105, Fig. 5, 510, claims 1 and 15, “receive, from a user device, a request to report a potential incident related to a transaction associated with a user account”; regarding selecting the selectable option to report the at least one transaction as potentially fraudulent: 0020, 0028)
generate an instruction to initiate a communication session between a fraud reporting system and the user computing device; and (claims 1 and 15, “select an intake workflow to resolve the potential incident,” see also 0021-0022)
transmit the generated instruction to the fraud reporting system, (claims 1 and 15 recite “select an intake workflow to resolve the potential incident …; present, to the user device, an initial screen associated with the intake workflow, …”; as per 0072, this recitation means that processors X may perform the ‘selecting’ and processors Y – different from processors X – may perform the ‘presenting’; this arrangement of different processors X and Y presupposes that the instruction generated as per the selecting step is transferred (transmitted) by the processors X (computing platform) to the processors Y (fraud reporting system), which perform the presenting step (initiate the communication session with the user computing device); likewise, 0053 states “The intake system 320 may include one or more devices capable of receiving, generating, storing, processing, providing, and/or routing information associated with customized intake handling for fraudulent … transactions”; according to this statement, a first “device” (computing platform) “generates” the “information” (generating an instruction …), and a second “device” (fraud reporting system) “provides” or “routes” the “information” to the user device (initiate the communication session with the user computing device), which presupposes that the instruction was transmitted from the first device (computing platform) to the second device (fraud reporting system) – this unpacking of 0053 is borne out by 0055 (“Furthermore, … a single device shown in FIG. 3 may be implemented as multiple, distributed devices.”), 0062 (“ In some implementations, one or more process blocks of FIG. 5 may be performed by the intake system 320. In some implementations, one or more process blocks of FIG. 5 may be performed by another device or a group of devices separate from or including the intake system 320”), and 0067 (“in some implementations, process 500 may include additional blocks, … different blocks, or differently arranged blocks than those depicted in FIG. 5. … The process 500 is an example of one process that may be performed by one or more devices described herein. These one or more devices may perform one or more other processes based on operations described herein, such as the operations described in connection with FIGS. 1A-1B.”))
wherein transmitting the instruction causes the fraud reporting system to initiate the communication session with the user computing device. (Fig. 1, 125, Fig. 5, 530, claims 1 and 15, “present, to the user device, an initial screen associated with the intake workflow, wherein the initial screen associated with the intake workflow includes one or more questions to request one or more user inputs that indicate one or more parameters related to the potential incident”)
It would have been obvious to one of ordinary skill in the art not later than the effective filing date of the claimed invention to have modified the combination of Narayanaswami's interactive purchase history map UI, as modified by Somashekar's teachings regarding clustering transaction data for display on a map, as further modified by Colon's teachings regarding using the shape of a transaction location indicator (on an interactive map showing transaction locations) to represent any of various characteristics of the transaction, and as further modified by Pawar’s transaction details UI including a selectable option to report a transaction as potentially fraudulent, by incorporating therein these further teachings of Pawar regarding initiating a communication with a fraud reporting system upon receipt of a user’s fraud report, because these further teachings of Pawar spell out detail of a robust fraud investigation/mitigation process and accordingly if incorporated in Narayanaswami would render Narayanaswami’s fraud mitigation more robust and effective, thus further improving Narayanaswami so as to better achieve Narayanaswami’s goals, see Narayanaswami, 0084-0085, MPEP 2143.I.C.,D.
Conclusion
The prior art made of record and not relied upon, as set forth in the accompanying Notice of References Cited (PTO-892), is considered pertinent to applicant's disclosure. Among the cited references:
Fiedler (US-6883708-B1) teaches collecting transaction data, including user and location data, and generating, based on the data, transaction maps to be provided with credit card bills, the maps showing the locations of the user’s transactions, with the functionality to group/categorize/filter transactions, e.g., by geographic area, time, amount, purchase category, or sensitivity, thus providing a more intuitive presentation of transactions that will permit cardholders to identify fraudulent charges more easily.
Carlson (US-20130262312-A1) teaches a UI displaying a map showing a pending transaction, determining if the transaction is risky, and if so sending the user a notification requesting user authorization of the transaction.
Chamberlain (US-20190318358-A1) teaches a UI displaying a map showing a pending transaction, determining if the transaction is risky, and if so sending the user a notification with risk mitigation actions for the user.
Martin (US-20220358509-A1) (Fig. 12) teaches a UI displaying a map showing locations of transactions, including varying the manner of display to indicate different characteristics of the transactions, and allowing user selection to obtain more detailed information regarding a specific transaction.
Votaw (Bank of America Corporation, assignee of the instant application) (US-20150088704-A1) teaches a UI displaying an interactive map including markers that may show transactions and related information/activities, where the transactions/ activities/information are captured from various sources and may be grouped according to various criteria/categories/tags, and user location information may be overlaid on the interactive map, for providing improved tracking and management related to how, where, when, and with whom a user enters into activities.
Davenport (US-20160343100-A1) teaches a UI displaying a geographic map with markers corresponding to the locations of transactions, where the transactions are of competitor companies of state owned enterprises, for the purpose of determining/ predicting company behavior and risk and proactively minimizing risk.
Graf (US-20140359510-A1) teaches a UI displaying a map with individually selectable location indicators, whereby user selection of a given location causes display of an informational sheet providing information about a business entity at the location, the display of the informational sheet occluding a portion of the map.
Carlson (US-20120094639-A1) teaches generating heat maps showing locations of transactions reflecting consumer spending, for the purpose of predicting consumer spending, and including where the heat map represents fraudulent transactions.
Matthews (US-20150058225-A1) teaches a UI displaying geographic regions and merchant locations, via which a user makes selections to authorize or restrict transactions based on location.
Yoder (US-20140236672-A1) teaches clustering transaction data associated with particular users and using the clustered data to generate a map display thereof.
Wolfowitz (US-20100262541-A1), 0040/Fig. 4, teaches using different shapes for interactive screen display icons corresponding to respective different payment methods, e.g., different credit cards or associated banks.
Saksonov (US-2016/0232635-A1) teaches generating and displaying a map including icons indicating the locations of respective transactions, where the icon may have attributes such as color, shape, etc. that represent any of various characteristics of the transaction that the icon represents, and where the icon can provide additional information about the transaction in response to a user interaction with the icon, see 0078.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS W PINSKY whose telephone number is (571)272-4131. The examiner can normally be reached on 8:30 am - 5:30 pm ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jessica Lemieux can be reached on 571-270-3445. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DOUGLAS W PINSKY/
Examiner, Art Unit 3626
1 Note the paragraph omitted here is set forth and addressed below.
Prosecution Insights