DETAILED ACTION
Status of Claims
The following is a final Office action in response to the communication filed 10/27/2025.
Claims 1, 11 and 15 have been amended. Claims 1-20 are currently pending and have been examined.
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 .
Response to Arguments
Applicant’s amendments and associated arguments, filed 10/27/2025, with respect to the rejection of claims 1-20 under 35 U.S.C. §101 have been considered but they are not persuasive. The newly amended limitations merely further characterize a computer-centric environment in which to apply the abstract idea without characterizing specifically what mechanism (or series of mechanisms) achieve a savings in processing power.
Applicant’s amendments and associated arguments, filed 10/27/2025, with respect to the rejection of claims 1-20 under 35 U.S.C. §103(a) have been considered but are not persuasive.
Applicant argues that the combination of applied references do not teach the amended claim limitations. Examiner respectfully disagrees. Grebenikof, in Fig 2 and [0039] describes a back-end architecture 14 that comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, including cloud-based text recognition 1010 for on-device optical character recognition (OCR) text detection for Latin-based characters, online travel agent (OTA) and aggregator machine learning 1020, a caching server 18, and a library that allows capture of screenshots from mobile device WebView. Grebenikof, in [0040], also discloses that the OCR technology is adapted and updated to run on flight data and interpret results in text form and may also be able to learn and adapt to new OTAs as users visit them, as opposed to a pre-defined list, and that interrupted OCR results can be matched with prior user data to match flights and find lower prices. This disclosure clearly establishes a computer centric environment for generating and processing screenshot of an itinerary to which OCR is applied to a select portion of the display (via user drag-based selection) to acquire lower priced matching options for said desired itinerary item. The image capture is of the most relevant portion of the display (i.e., the itinerary portion) and the processing system learns and is adaptive, further saving processing power of the server (though the claims do not establish the relative standard to which the power savings is associated).
Applicant further argues that Grebenikof merely recites a sticker icon to identify cheaper flight itineraries an does not teach image data that includes the screenshot of the itinerary usable for identifying itinerary recommendations. Examiner respectfully disagrees. Grebenikof, in [0044] and FIGS. 9A-9C and 10A-10B, discloses a mobile app that includes an icon to select between drawing a shape such as a rectangle or a circle on a desired flight, where said gesture may be taken as a screenshot, and optical character recognition (OCR) is then applied to said screenshot, logical matching is applied in real time to recognize and match the text with flight details. Grebenikof, in Figs. 9A-9B and paragraphs p0053]-[0054] further elaborate on how the matching flight details are used to query cheaper options. In Grebenikof, the desired flight is a desired itinerary, the screenshot must contain an image with text such that the OCR can be applied thereto. Further, the subsequent identification of matching flights with cheaper options represents identified itinerary recommendations. Moreover, the acquired flight details that are recognized and matched amount to query attributes.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. More specifically, claims 1, 11 and 15 have been amended to recites “generating… one or more query attributes to be used for one or more web resource requests for travel data such that a server processes a limited amount of the image data in a manner that saves processing power of the server” (amended limitations underlined), but the specification for the instant claims does not provide written description support for this limitation. Rather, the specification provides support for validating metadata associated with the image, and verifying the image is an expected content type/format. The only disclosure that addresses processing power is an enforcement on the size of the image to “prevent excessively large or resource-intensive images from being processed”. See [0020], [0056] of the specification as filed.
Dependent claims 2-10, 12-14 and 16-20 do not act to cure the deficiencies of claims 1, 11 and 15 and are thereby rejected under at least the same rationale.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1 of the Subject Matter Eligibility Test entails considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: Process, machine, manufacture, or composition of matter.
Claims 1-20 are directed to a method (process), a system (machine or manufacture), and a non-transitory medium (manufacture), respectively. As such, the claims are directed to statutory categories of invention.
If the claim recites a statutory category of invention, the claim requires further analysis in Step 2A. Step 2A of the Subject Matter Eligibility Test is a two-prong inquiry. In Prong One, examiners evaluate whether the claim recites a judicial exception.
Claim 1 recites abstract limitations, including those indicated in bold below:
1. A method, comprising: receiving, from a client device, image data representing a screenshot of an itinerary; generating, from the image data and based at least in part on an indication that the image data includes the screenshot of the itinerary usable for identifying itinerary recommendations and executable in a computer-centric environment based on computing resources associated with the image data, one or more query attributes to be used for one or more web resource requests for travel data such that a server processes a limited amount of the image data in a manner that saves processing power of the server; transmitting, by the server, one or more requests for the travel data that satisfy the one or more query attributes; receiving, at a first time and in response to the one or more requests, a first portion of travel data that satisfies the one or more query attributes; generating, based at least in part on receiving the first portion of travel data, a primary itinerary recommendation, the primary itinerary recommendation comprising a first set of one or more itineraries that satisfy the one or more query attributes; transmitting the primary itinerary recommendation to the client device for presentation via a user interface; receiving, at a second time after the first time and in response to the one or more requests, a second portion of travel data satisfying the one or more query attributes; generating, based at least in part on receiving the second portion of travel data, a secondary itinerary recommendation, the secondary itinerary recommendation comprising a second set of one or more itineraries that satisfy the one or more query attributes, wherein the second set of one or more itineraries differs at least in part from the first set of one or more itineraries; and transmitting the secondary itinerary recommendation to the client device for presentation via the user interface.
Claims 11 and 15 recite analogous limitations to those identified as abstract above with respect to claim 1.
These limitations, as drafted, are a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind, or by a human using pen and paper, and therefore recite mental processes. More specifically, other than reciting processing devices, nothing in the claim element precludes the aforementioned steps from practically being performed in the human mind, or by a human using pen and paper. The mere recitation of generic computing devices does not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
If the claim recites a judicial exception in step 2A Prong One , the claim requires further analysis in step 2A Prong Two. In step 2A Prong Two, examiners evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
Claim 1 recites additional elements, which are underlined below.
1. A method, comprising: receiving, from a client device, image data representing a screenshot of an itinerary; generating, from the image data and based at least in part on an indication that the image data includes the screenshot of the itinerary usable for identifying itinerary recommendations and executable in a computer-centric environment based on computing resources associated with the image data, one or more query attributes to be used for one or more web resource requests for travel data such that a server processes a limited amount of the image data in a manner that saves processing power of the server; transmitting, by the server, one or more requests for the travel data that satisfy the one or more query attributes; receiving, at a first time and in response to the one or more requests, a first portion of travel data that satisfies the one or more query attributes; generating, based at least in part on receiving the first portion of travel data, a primary itinerary recommendation, the primary itinerary recommendation comprising a first set of one or more itineraries that satisfy the one or more query attributes; transmitting the primary itinerary recommendation to the client device for presentation via a user interface; receiving, at a second time after the first time and in response to the one or more requests, a second portion of travel data satisfying the one or more query attributes; generating, based at least in part on receiving the second portion of travel data, a secondary itinerary recommendation, the secondary itinerary recommendation comprising a second set of one or more itineraries that satisfy the one or more query attributes, wherein the second set of one or more itineraries differs at least in part from the first set of one or more itineraries; and transmitting the secondary itinerary recommendation to the client device for presentation via the user interface.
Claim 11 further recites a system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that, when executed, cause the system to perform the method of claim 1.
Claim 15 further recites one or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform the method of claim 1.
The functions (i.e., transmitting/receiving/storing/processing/displaying data) of the claimed computer components (client device, server, system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions; one or more non-transitory computer-readable media storing instructions .. executed…[by] one or more processors; the computer-centric environment) are recited at a high level of generality and are merely invoked as tool to perform the abstract idea.
Additionally, the receipt of screenshot information from a client device is recited at a high level of generality (i.e. as a general means of gathering information for evaluation), and amounts to mere data gathering, which is a form of pre-solution activity
Furthermore, the presentation via the user interface is recited at a high level of generality (i.e. as a general means of displaying the outcome of the analysis), which is a form of insignificant post-solution activity
Accordingly, 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.
If the additional elements do not integrate the exception into a practical application in step 2A Prong Two, then the claim is directed to the recited judicial exception, and requires further analysis under Step 2B to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself).
As discussed above, the additional elements (client device, server, system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions; one or more non-transitory computer-readable media storing instructions .. executed…[by] one or more processors; the computer-centric environment) amount to mere instructions to apply the exception. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
As indicated above, the receipt of screenshot information from a client device is recited at a high level of generality (i.e. as a general means of gathering information for evaluation), and amounts to mere data gathering, which is a form of pre-solution activity and the presentation via the user interface is recited at a high level of generality (i.e. as a general means of displaying the outcome of the analysis), which is a form of insignificant post-solution activity. The specification demonstrates the well-understood, routine, conventional nature of additional elements as it describes the additional elements as well-understood or routine or conventional (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. §112(a). Additionally, the Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection or receipt of data over a network is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). Furthermore, the Content Extraction and Transmission court decision cited in MPEP 2106.05(d)(II) indicate that electronically scanning or extracting data from a document is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). MPEP 2106.05(d)(II), and the cases cited therein, including in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function.
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea.
Claims 2-4 and 12-14 recite limitations that further characterize the generation of the query attributes, which further characterizes the previously recited abstract concepts. Claims 2 and 12 recite the additional elements of transmitting data between devices over a network and performing optical character recognition of image data, which have been identified above as functions that are extra-solution and well-understood, routine and conventional computing functions. Claims 4 and 14 recite the additional element of a machine learning model, which when recited at this level of generality amounts to instructions to implement the abstract idea on a generic computer.
Claim 5 recites limitations that further characterize the generation of the itinerary recommendations, which further characterizes the previously recited abstract concepts. Claim 5 also recites the additional element of a machine learning model, which when recited at this level of generality amounts to instructions to implement the abstract idea on a generic computer.
Claims 6 and 16 recite limitations that further characterize the generation of the itinerary recommendations, which further characterizes the previously recited abstract concepts. For the reasons described above with respect to claims 1, 11 and 15, this judicial exception is not meaningfully integrated into a practical application, or significantly more than the abstract idea.
Claims 7 and 17 recite limitations that further characterize the generation of the recommendation and associated option to purchase, which further characterizes the previously recited abstract concepts. Claims 7 and 17 also recite the additional elements of user interface control and subsequent display of information, which amount to extra-solution activity. The specification demonstrates the well-understood, routine, conventional nature of additional elements as it describes the additional elements as well-understood or routine or conventional (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. §112(a). Additionally, the Symantec, Internet Patent Corp. court decision cited in MPEP 2106.05(d)(II) indicate that a web browser’s back and forward functionality is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). Additionally, the Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere collection or receipt of data over a network is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here).
Claims 8 and 18 recite limitations directed to threshold periods of times associated with the request for travel data and subsequent instruction to cease data collection after a threshold period of time, which is a process that can be performed in the human mind and is therefore a mental process. Claims 8 and 18 also recite the additional element of transmitting the instructions, which as indicated above amounts to extra-solution activity that is well-understood, routine and conventional.
Claims 9 and 19 recite limitations that represent additional iterations of the limitations presented and analyzed above with respect to claims 1, 11 and 15. See the analysis of claims 1, 11 and 15 above.
Claims 10 and 20 recite limitations that further characterize the generation of the itinerary recommendations, which further characterizes the previously recited abstract concepts. Claims 10 and 20 also recite the additional element of transmitting information between devices, which as indicated above amounts to extra-solution activity that is well-understood, routine and conventional.
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 (i.e., changing from AIA to pre-AIA ) 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 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.
Claim(s) 1-4, 7-8, 10-15, 17-18, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Grebenikof (US 20200410566 A1) in view of Kelly (US 20150199621 A1).
Grebenikof is directed to a system and method for dynamic search, price comparison and optimization.
With respect to claims 1 and 11, Grebenikof discloses:
A method, comprising:
Grebenikof, Fig. 2
receiving, from a client device, image data representing a screenshot of an itinerary;
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. Clicking the sticker icon 114 directs the user to the flight details pop-up 116 and re-direction link 118 to the unique cheaper offer's website to book the flight. Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details. All flights marked by the drag and save sticker icon 114 are automatically saved 1155 in a dedicated savings page.
Grebenikof [0045] Exemplary embodiments of the mobile app may utilize various solutions to optimize searching and tracking capability, user experience, maintenance, and support. In addition to user movements such as clicking and dragging, rectangular or circular movements or drawings can be used. The system may use a technology that allows the drawing of perfect or imperfect rectangles or circles to recognize patterns and screenshot the relevant sections accordingly.
See also Grebenikof [0054]
generating, from the image data and based at least in part on an indication that the image data includes the screenshot of the itinerary usable for identifying itinerary recommendations and executable in a computer-centric environment based on computing resources associated with the image data, one or more query attributes to be used for one or more web resource requests for travel data such that a server processes a limited amount of the image data in a manner that saves processing power of the server;
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. ... Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details. All flights marked by the drag and save sticker icon 114 are automatically saved 1155 in a dedicated savings page.
Grebenikof Fig 2 [0039] As best seen in FIG. 2, back-end architecture 14 comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, some of which are on the user device and some of which are on the cloud. These include cloud-based text recognition 1010 for on-device optical character recognition (OCR) text detection for Latin-based characters, online travel agent (OTA) and aggregator machine learning 1020, as well as a caching server 18. A library allows capture of screenshots from mobile device WebView.
Grebenikof [0040] The OCR technology is adapted and updated to run on flight data and interpret results in text form. Customized logic rules using coordinates and text positioning applied on the recognized text filter the information and match it with corresponding flight data. … It may also be able to learn and adapt to new OTAs as users visit them, as opposed to a pre-defined list. Exemplary embodiments can match interrupted OCR results with prior user data to match flights and find lower prices.
transmitting, by a server, one or more requests for the travel data that satisfy the one or more query attributes;
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. Clicking the sticker icon 114 directs the user to the flight details pop-up 116 and re-direction link 118 to the unique cheaper offer's website to book the flight. Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details
Grebenikof [0054] As shown in FIGS. 9A-9B, to select a flight option, the user drags the “Drag and Save” sticker icon 114 over the desired flight. This action queries the system's back-end architecture 14 for potential savings and a cheaper option. At this time, the system's server submits a predictive search query to a group of virtual private servers accessed on chosen member devices around the world. This group is selected based on the members having the best online profiles and locations. Through the browser extensions 16, the back-end architecture 14 runs queries on OTAs or aggregators through the chosen member devices distributed across several countries or locations to find the best possible price for the user's flight and sends 1145 the results back to the user's device 1000 via the caching server 18.
See also Grebenikof [0039]-[0040] As best seen in FIG. 2, back-end architecture 14 comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, some of which are on the user device and some of which are on the cloud.; Grebenikof [0045] – [0047];
receiving, at a first time and in response to the one or more requests, a first portion of travel data that satisfies the one or more query attributes;
Grebenikof [0054] As shown in FIGS. 9A-9B, to select a flight option, the user drags the “Drag and Save” sticker icon 114 over the desired flight. This action queries the system's back-end architecture 14 for potential savings and a cheaper option. At this time, the system's server submits a predictive search query to a group of virtual private servers accessed on chosen member devices around the world. This group is selected based on the members having the best online profiles and locations. Through the browser extensions 16, the back-end architecture 14 runs queries on OTAs or aggregators through the chosen member devices distributed across several countries or locations to find the best possible price for the user's flight and sends 1145 the results back to the user's device 1000 via the caching server 18.
generating, based at least in part on receiving the first portion of travel data, a primary itinerary recommendation, the primary itinerary recommendation comprising a first set of one or more itineraries that satisfy the one or more query attributes; transmitting the primary itinerary recommendation to the client device for presentation via a user interface;
Grebenikof [0053] the app ranks OTAs based on their pricing and which locations provide the best prices.
Grebenikof [0054] As shown in FIGS. 9A-9B, to select a flight option, the user drags the “Drag and Save” sticker icon 114 over the desired flight. This action queries the system's back-end architecture 14 for potential savings and a cheaper option. At this time, the system's server submits a predictive search query to a group of virtual private servers accessed on chosen member devices around the world. This group is selected based on the members having the best online profiles and locations. Through the browser extensions 16, the back-end architecture 14 runs queries on OTAs or aggregators through the chosen member devices distributed across several countries or locations to find the best possible price for the user's flight and sends 1145 the results back to the user's device 1000 via the caching server 18.
Grebenikof [0055] As best seen in FIG. 9C, the app may show the potential savings for the flight on the sticker icon 114. The user then clicks the sticker icon 114, and the app directs the user to the flight details pop-up 116 and/or a re-direction link 118 to the cheaper offer's website.
Grebenikof, in Fig. 10A (reference to frequent changes) and [0048] (reference to changes and associated updates), strongly suggests receipt of second portions of travel data (i.e. iterative data updates).
Kelly, in a similar field of endeavor, is directed to a method and system for dynamic information connection search engine. Kelly discloses
receiving, at a second time after the first time and in response to the one or more requests, a second portion of travel data satisfying the one or more query attributes;
generating, based at least in part on receiving the second portion of travel data, a secondary itinerary recommendation, the secondary itinerary recommendation comprising a second set of one or more itineraries that satisfy the one or more query attributes, wherein the second set of one or more itineraries differs at least in part from the first set of one or more itineraries; and
transmitting the secondary itinerary recommendation to the client device for presentation via the user interface.
Kelly [0195] The Copilot Servlet determines a set of supplier systems to search in an attempt to find items that best satisfy the received request. The determination may be made using information including, but not limited to, the contents of the information received in the request, the user's personal information, the user's current selections in the client user interface (e.g., if the Bar is open), the recent history of searches, the amount of bandwidth the searches have recently used on each supplier system, other information about suppliers, and/or the history of prior searches (e.g., of similar types by similar users).
Kelly [0196] The Copilot Servlet acquires a set of search adapter objects from an internal resource pool, and tasks one to search each of the selected suppliers. Each search adapter may perform its search independently and asynchronously from the others, so that the subsequent steps in the Copilot Servlet processing sequence can handle incremental search results.
Kelly [0199] The complexity of making pruning/filtering decisions on the data items found may be increased by the results being received from different suppliers at different times, and being forwarded to the client for incremental display as quickly as possible. In order to provide incremental results to the client, the server may apply filtering decisions to individual search results without certain data about the results that may or may not be subsequently received from suppliers that have not yet responded to the search request.
Kelly [0200] In one example (which example is intended to be illustrative and not restrictive), a numeric score (applying the desired criteria) may be generated for each individual data item. Items achieving a score above a certain threshold may be sent on immediately, items falling bellow a lower threshold may be discarded, and those between the two thresholds may be retained for further consideration. The system may adopt a target number of results to return from any search (or possibly a different target number for each category of search, such as the air travel, hotel, and rental car reservation categories). Since the number of suppliers being searched may be known at the outset of a search (although an alternate embodiment can add the ability to start new searches of different suppliers incrementally if the initially-received results were judged inadequate), the threshold for deciding which results should be forwarded to a client can be adjusted up or down after each supplier's results are received and it can be determined whether the average number of results per supplier so far sent to the client is above or below the target average number of displayed results per supplier.
It would have been obvious to one of ordinary skill in the art at the time the invention was made to include the sequential conveyance of ranked search results, as taught by Kelly, in the search system of Grebenikof, as the system of Grebenikof acquires and ranks results from multiple provider sources and would therefore be improved through adaptations that consider response times from each respective provider source.
Additionally and/or alternatively, one of ordinary skill in the art would have recognized that applying the known technique of Kelly to Grebenikof would have yielded predictable results and resulted in an improved system capable of integrating results received at different times based on iterative requests and/or updates to pricing/availability of limited quantity products.
With respect to claim 11, Grebenikof further discloses a system comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions (Grebenikof Fig. 2, also [0037]-[0038])
With respect to claim 15, Grebenikof further discloses one or more non-transitory computer-readable media storing instructions (Grebenikof Fig. 2, also [0037]-[0038])
With respect to claims 2 and 12, the combination of Grebenikof and Kelly disclose the method and system of claims 1 and 11. Grebenikof further discloses: wherein generating the one or more query attributes from the image data comprises: transmitting, over a network, a first request to perform optical character recognition (OCR) on the image data, the image data associated with a text layout; receiving, in response to the first request, text data associated with the image data; reformatting the text data to correspond to the text layout associated with the image data; transmitting, over the network, a second request to generate the one or more query attributes in a structured data format using the text data; and receiving, in response to the second request, the one or more query attributes in the structured data format.
Grebenikof [0039] As best seen in FIG. 2, back-end architecture 14 comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, some of which are on the user device and some of which are on the cloud. These include cloud-based text recognition 1010 for on-device optical character recognition (OCR) text detection for Latin-based characters, online travel agent (OTA) and aggregator machine learning 1020, as well as a caching server 18. A library allows capture of screenshots from mobile device WebView.
Grebenikof [0040] Open source cloud-based technology for more complex and in-depth OCR text recognition may be used to identify different fonts and styles. The OCR technology is adapted and updated to run on flight data and interpret results in text form. Customized logic rules using coordinates and text positioning applied on the recognized text filter the information and match it with corresponding flight data. The OCR technology may be utilized to crack the logic of the OTAs, which the system may organize into groups and subgroups. In addition, a stronger and more general logic applies OCR and matches data in a more general way that is not OTA-specific or OTA-group specific. It may also be able to learn and adapt to new OTAs as users visit them, as opposed to a pre-defined list. Exemplary embodiments can match interrupted OCR results with prior user data to match flights and find lower prices.
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. Clicking the sticker icon 114 directs the user to the flight details pop-up 116 and re-direction link 118 to the unique cheaper offer's website to book the flight. Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details. All flights marked by the drag and save sticker icon 114 are automatically saved 1155 in a dedicated savings page.
In addition, as shown above, Kelly discloses iterative functions executed during the acquisition of information from multiple providers.
With respect to claims 3 and 13, the combination of Grebenikof and Kelly disclose the method and system of claims 1 and 12. Grebenikof further discloses: wherein the second request includes an instruction to limit a length of the structured data format of the one or more query attributes.
Grebenikof [0039] As best seen in FIG. 2, back-end architecture 14 comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, some of which are on the user device and some of which are on the cloud. These include cloud-based text recognition 1010 for on-device optical character recognition (OCR) text detection for Latin-based characters, online travel agent (OTA) and aggregator machine learning 1020, as well as a caching server 18. A library allows capture of screenshots from mobile device WebView.
Grebenikof [0040] Open source cloud-based technology for more complex and in-depth OCR text recognition may be used to identify different fonts and styles. The OCR technology is adapted and updated to run on flight data and interpret results in text form. Customized logic rules using coordinates and text positioning applied on the recognized text filter the information and match it with corresponding flight data. The OCR technology may be utilized to crack the logic of the OTAs, which the system may organize into groups and subgroups. In addition, a stronger and more general logic applies OCR and matches data in a more general way that is not OTA-specific or OTA-group specific. It may also be able to learn and adapt to new OTAs as users visit them, as opposed to a pre-defined list. Exemplary embodiments can match interrupted OCR results with prior user data to match flights and find lower prices.
With respect to claims 4 and 14, the combination of Grebenikof and Kelly disclose the method and system of claims 1 and 11. Grebenikof further discloses: wherein generating the one or more query attributes from the image data comprises inputting the image data into a machine learning model configured to receive the image data as input and generate the one or more query attributes in a structured data format as output.
Grebenikof [0039] As best seen in FIG. 2, back-end architecture 14 comprises a complex series of custom components, services, databases, tracking tools, and third-party integrations, some of which are on the user device and some of which are on the cloud. These include cloud-based text recognition 1010 for on-device optical character recognition (OCR) text detection for Latin-based characters, online travel agent (OTA) and aggregator machine learning 1020, as well as a caching server 18. A library allows capture of screenshots from mobile device WebView. Fully custom developed code and scripts for various features such as the drag and save sticker and DOM Manipulation and listeners scripts are described in more detail herein.
Grebenikof [0040] In exemplary embodiments, cloud-based components and features of the back-end architecture 14 include one or more of the following. An open source cloud-based technology for more complex and in-depth OCR text recognition may be used to identify different fonts and styles. The OCR technology is adapted and updated to run on flight data and interpret results in text form. Customized logic rules using coordinates and text positioning applied on the recognized text filter the information and match it with corresponding flight data. The OCR technology may be utilized to crack the logic of the OTAs, which the system may organize into groups and subgroups. In addition, a stronger and more general logic applies OCR and matches data in a more general way that is not OTA-specific or OTA-group specific. It may also be able to learn and adapt to new OTAs as users visit them, as opposed to a pre-defined list. Exemplary embodiments can match interrupted OCR results with prior user data to match flights and find lower prices.
Grebenikof [0046] The Main Flights Database may be located in a Shared MongoDB Cluster 1040 to provide higher availability during writes operations. Machine learning allows input of flight screens to enhance data capture optimization.
With respect to claims 7 and 17, the combination of Grebenikof and Kelly disclose the method and medium of claims 1 and 15. Grebenikof further discloses:
Grebenikof further discloses generating, based at least in part on receiving the first portion of travel data and the second portion of travel data, a purchase recommendation for an itinerary, the purchase recommendation associated with a control; receiving a selection of the control; and in response to receiving the selection of the control, causing the user interface to present at least one of: a first option to purchase one or more plane tickets associated with the itinerary; or a second option to sign up for a price alert for one or more plane tickets.
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. Clicking the sticker icon 114 directs the user to the flight details pop-up 116 and re-direction link 118 to the unique cheaper offer's website to book the flight. Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details. All flights marked by the drag and save sticker icon 114 are automatically saved 1155 in a dedicated savings page.
Grebenikof [0055] As best seen in FIG. 9C, the app may show the potential savings for the flight on the sticker icon 114. The user then clicks the sticker icon 114, and the app directs the user to the flight details pop-up 116 and/or a re-direction link 118 to the cheaper offer's website. The user can then book the flight for the cheapest price on that website 119, shown in FIGS. 11-13B.
In addition, as shown above with respect to the rejection of the independent claims, Kelly further discloses the iterative nature of requests for, responses from, and display of responses from multiple providers of itinerary information.
With respect to claims 8 and 18, the combination of Grebenikof and Kelly disclose the method and medium of claims 1 and 15. Kelly further discloses: further comprising: determining a threshold period of time has passed since transmitting the one or more requests for the travel data; and causing the server to stop receiving travel data based at least in part on determining the threshold period of time has passed.
Kelly [0110] For example (which example is intended to be illustrative and not restrictive), the JavaScript that executes within the Bar may start a time-out counter each time a user action begins a new search. This counter may be used to control the period of time in which the search results are considered valid (which may be an important consideration when dealing with travel bookings, including airline tickets). In this regard, as search results expire, any electronic links provided to the associated supplier over which the associated travel item or component could be reserved or purchased may be deactivated.
Kelly [0111] In other words, since certain pricing and availability fluctuate rapidly (e.g., as relates to airline tickets), it may be important to prevent the user from attempting to purchase a ticket after it becomes unavailable. To enable this, the JavaScript may wait for a period of time (e.g., several minutes) after the start of the search. After this period, the JavaScript may notify the user that the results are no longer valid and the JavaScript may deactivate the purchasing controls associated with each result displayed.
Kelly [0112] In one example (which example is intended to be illustrative and not restrictive), the time-out period may be approximately 10 minutes. Of note, this time-out period should be closely related to the individual times that the travel supplier systems will hold a reservation for purchase after they respond to a query, a period that may have to be determined empirically and/or separately for each supplier. Therefore, the time-out period may be different in systems designed to search for different types of information, or different for each result item within a set of search results. Because the timeout may tracked be within the JavaScript code (which may be downloaded from the server each time the Bar is opened), the JavaScript code may be easily changed independently of having to create and distribute new clients.
Kelly [0115] On the other hand, separate searches may be performed by the user for, e.g., airline reservations, rental car reservations, and hotel reservations. For example (which example is intended to be illustrative and not restrictive), the user may select among these three types of search using tab controls displayed in the Bar. The client-side JavaScript may be capable of maintaining separate sets of search results for each category once searches have been performed, and may have separate time-out counters for each. It may therefore be possible for the user to search for all three types of travel reservations, and for the user to switch back and forth among the different result displays without interfering with the separate expiration counts on each set of search results.
It would have been obvious to one of ordinary skill in the art at the time the invention was made to limit the receipt of data based on a time threshold, as taught by Kelly, in the search system of Grebenikof and Kelly, as the time in which the search results are considered valid is an important consideration when dealing with travel bookings, including airline tickets, the offers of which may expire (Kelly [0110]-[0115]).
Additionally and/or alternatively, one of ordinary skill in the art would have recognized that applying the threshold time periods of Kelly to the booking system of Grebenikof would have yielded predictable results and resulted in an improved system. It would have been recognized that applying threshold time periods of Kelly to the teaching of Grebenikof would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate display of time-sensitive results received at different times from multiple providers, the available quantities of which may expire before users are able to book.
With respect to claims 10 and 20, the combination of Grebenikof and Kelly disclose the method and medium of claims 1 and 15.
Grebenikof further discloses receiving, from the client device and in addition to the image data, one or more search criteria for a travel reservation; and wherein generating the primary itinerary recommendation and the secondary itinerary recommendation is based at least in part on the one or more search criteria.
Grebenikof [0020] FIG. 6 is a perspective view of an exemplary embodiment of a system and method of dynamic searching, price comparison, and optimization showing a mobile application page for selecting an OTA/aggregator;
Grebenikof [0021] FIG. 7 is a perspective view of an exemplary embodiment of a system and method of dynamic searching, price comparison, and optimization showing a mobile application flight itinerary search page;
Grebenikof [0042] Turning to FIGS. 3-13B, exemplary embodiments of a mobile application 100 providing dynamic searching, price comparison, and price optimization will now be described. The mobile application includes an optional sign-up process 102 so a user can create his or her unique profile 106 and a sign-in 104 to access the mobile app. The mobile app may collect information about the user, including but not limited to, name, email address, date of birth, gender, profile picture, hashed and encrypted passwords, geolocation, device name and type, and operating system name and version. In exemplary embodiments, an active database holds all active users' personal data.
Grebenikof [0043] As best seen in FIGS. 6 and 7, there are one or more pages for inserting a flight itinerary 108 as well as pages for selecting an OTA/aggregator 110 such as Priceline, Orbitz or Kayak. Then the mobile app loads the interface of the selected aggregator with the results set 112 displayed, as shown in FIG. 8.
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Grebenikof (US 20200410566 A1) in view of Kelly (US 20150199621 A1) and further in view of Annakov (US 20210264326).
With respect to claim 5, the combination of Grebenikof and Kelly disclose the method of claim 1. Grebenikof and Kelly, as shown above, discloses the use of machine learning models, the generation of user profile information based on user interaction tacking, iterative requests and sequential responses to said requests, and ranked display of results, but does not explicitly disclose the limitations as claimed. (Grebenikof [0042] - [0044] FIGS. 2, 9A-9C and 10A-10B; Grebenikof [0054] - [0055]; Kelly [0195])
Annakov discloses methods and systems, including an automated flight-recommendation-and-booking system that provide accurate, short lists of flights that best match a user's preferences and flight parameters specified by the user. Annakov discloses: wherein generating the primary itinerary recommendation and the secondary itinerary recommendation comprises inputting the first portion of travel data, the second portion of travel data, and user data into a machine learning model configured to receive the first portion of travel data, the second portion of travel data, and user data as input and generate the primary itinerary recommendation and the secondary itinerary recommendation as output.
Annakov [0004] The current document is directed to methods and systems, including an automated flight-recommendation-and-booking system, that provide accurate, short lists of flights that best match a user's preferences and flight parameters specified by the user. In addition, the automated flight-recommendation-and-booking system learns, over time, to provide the most desirable flights to each user, and thus represents a type of machine-learning system. The currently disclosed systems continuously monitor and store detailed information with regard to users' interactions with the systems, flight information, and other types of information that can be used to more accurately identify suitable flights for particular users. The currently disclosed systems initially provide, to a requesting user, information for only a small number of flights that closely correspond to the user's preferences and flight parameters, so that the user does not need to search through pages of returned results in order to identify flights that best meet his or her needs and preferences. Furthermore, the currently disclosed systems continuously store information about user interactions as well as information about airlines, flights offered by airlines, and other types of information relevant to air travel in order to be able to subsequently find and present information about flights that closely match each user's preferences and flight parameters. The currently disclosed systems employ automated machine-learning methods to continuously track users' searches and flight selections in order learn users' preferences and to track users' preferences as they change and evolve, over time. As a result, the currently disclosed methods and systems provide simple, easy-to-understand, and highly personalized flight-recommendation-and-booking services to users, similar to the personalized services previously provided by travel agents, but with the many advantages that only automated, Internet-connected systems can provide.
It would have been obvious to one of ordinary skill in the art at the time the invention was made to include additional machine learning modeling, as taught by Annakov, in the combined search system of Grebenikof and Kelly, to facilitate the creation of personalized search results and result in an improved/optimized search engine in which the user does not need to search through pages of returned results in order to identify flights that best meet his or her needs and preferences.
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Grebenikof (US 20200410566 A1) in view of Kelly (US 20150199621 A1) and further in view of Iyer (US 20210034684 A1)
With respect to claims 6 and 16, the combination of Grebenikof and Kelly disclose the method and medium of claims 1 and 15. Grebenikof and Kely, as shown above, discloses a user profile compiled based on user interaction tacking, but does not recite weighting of query attributes based on said user profile (Grebenikof [0042] - [0044] FIGS. 2, 9A-9C and 10A-10B; Grebenikof [0052] - [0055]; Kelly [0195])
Iyer discloses a system and method of generating personalized search results. Iyer discloses weighting the one or more query attributes based at least in part on a preference associated with a user profile of the client device; and wherein generating the primary itinerary recommendation and the secondary itinerary recommendation is based at least in part on the weighting
Iyer [0072] At step 606, the set of top N relevance-based search results and the set of top N user-specific results are merged into a single mixed set of search results. For example, in some embodiments, attribute weightings are determined and/or received for one or more attributes shared by the set of top N relevance-based search results and the set of top N user-specific results. The set of top N relevance-based search results and the set of top N user-specific results may be merged using, for example, a pairwise comparison of attributes based on the attribute weightings.
Iyer [0073] FIG. 12 illustrates one embodiment of a method 700 of generating and assigning attribute weights, in accordance with some embodiments. At step 702, the query attributes for a specific query and a set of item attributes for the top N items associated with a search query are obtained. The top N items may be identified by engagement data, such as, for example, the number of times that an item was returned for a search query, selected (e.g., clicked-on/click-through) by a user, added to a user's cart, purchased by a user, etc. For example, in one embodiment, the top N items include the top five items added to a cart after a specific search query is received as determined by aggregated past engagement data. Although specific embodiments are discussed herein, it will be appreciated that the top N items can include any suitable number of items.
Iyer [0074] At step 704, the query attributes are compared to the item attributes for the top N items to determine the number of matches between the query attributes and the item attributes. For example, in some embodiments, a count is generated for each query attribute identified for the search query. The count represents the number of times a given query attribute appears as or otherwise matches an item attribute. At step 706, the probability of a user maintaining the attribute, e.g., the probability of a query attribute having the same (or matching) value as an attribute of an item added to the user's cart, is determined. In some embodiments, the calculated probability for each query attribute corresponds to a weighting of that query attribute for the search query.
It would have been obvious to one of ordinary skill in the art at the time the invention was made to include attribute weighting, as taught by Iyer, in the combined search system of Grebenikof and Kelly, to facilitate the creation of personalized search results (Iyer, abstract) and result in an improved/optimized search engine.
Claim(s) 9 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Grebenikof (US 20200410566 A1) in view of Kelly (US 20150199621 A1) and further in view of Cordesses (US 20180329926).
With respect to claims 9 and 19, the combination of Grebenikof and Kelly disclose the method and medium of claims 1 and 15.
Grebenikof further discloses receiving, from the client device, second image data representing a second screenshot; generating, based at least in part on the second image data, a second set of one or more query attributes to be used for a second number of one or more web resource requests for second travel data; transmitting, by the server, a second number of one or more requests for the second travel data that satisfies the second set of one or more query attributes; receiving, in response to the second number of one or more requests, the second travel data; generating, based at least in part on receiving the second travel data, a third set of one or more itineraries that satisfy the second set of one or more query attributes; and transmitting the third set of one or more itineraries to the client device for presentation via the user interface.
Grebenikof [0044] Referring to FIGS. 9A-9C and 10A-10B, the mobile app includes a “Drag and Save” sticker icon 114 which can be dragged over any desired flight and query the back-end architecture for potential savings and a cheaper option. Clicking the sticker icon 114 directs the user to the flight details pop-up 116 and re-direction link 118 to the unique cheaper offer's website to book the flight. Alternatively, the user could hit an icon to select between drawing a shape such as a rectangle or a circle on a desired flight. The gesture made by the user may be taken as a screenshot and OCR with logical matching is applied in real time to recognize and match the text with flight details. All flights marked by the drag and save sticker icon 114 are automatically saved 1155 in a dedicated savings page. Any saved data may be maintained indefinitely in a History database separate from the user personal information database.
Grebenikof [0054] As shown in FIGS. 9A-9B, to select a flight option, the user drags the “Drag and Save” sticker icon 114 over the desired flight. This action queries the system's back-end architecture 14 for potential savings and a cheaper option. At this time, the system's server submits a predictive search query to a group of virtual private servers accessed on chosen member devices around the world. This group is selected based on the members having the best online profiles and locations. Through the browser extensions 16, the back-end architecture 14 runs queries on OTAs or aggregators through the chosen member devices distributed across several countries or locations to find the best possible price for the user's flight and sends 1145 the results back to the user's device 1000 via the caching server 18.
Grebenikof [0055] As best seen in FIG. 9C, the app may show the potential savings for the flight on the sticker icon 114. The user then clicks the sticker icon 114, and the app directs the user to the flight details pop-up 116 and/or a re-direction link 118 to the cheaper offer's website. The user can then book the flight for the cheapest price on that website 119, shown in FIGS. 11-13B.
In addition, as shown above with respect to the rejection of the independent claims, Kelly further discloses the iterative nature of requests for, responses from, and display of responses from multiple providers of itinerary information.
The combination of Grebenikof and Kelly do not recite that any iterative screenshot contains a landmark that is considered in the generation of query attributes.
Cordesses (US 20180329926), discloses generation of a search query using the image of a landmark (Cordesses [0029]).
One of ordinary skill in the art would have recognized that applying image based query generation (e.g., of a landmark) of Cordesses would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cordesses to the teaching of Grebenikof and Kelly would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate image analysis in the generation of search queries that more fully capture travel intent of a user.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Relevant prior art, Thukkharam (12,424,009 B1), disclosing (18) Instead of performing OCR on a full image capture screenshot of the entire page, the OCR can be performed on a significantly reduced area (e.g., less than 75% of the maximum size of page). In some examples, OCR is performed on less than 50% of a page. In some examples, OCR is performed on no more than 25% of a page. Reducing the total percentage of the screen for which OCR is to be performed is beneficial for CPU resource constrained platforms.
Relevant prior art, Chintakindi (WO2020069154 A1), discloses the extraction, formatting and storge of oeservation data from a screenshot, but does not disclose the use of said data for any form of query.
Relevant prior art Ghahramani discloses the user may provide non-textual input, such as an image or a video of a city as the travel criteria.
Relevant prior art, Wen (US 20090157664), discloses the submission of a plain-text document containing an itinerary, wherein the document is parsed, categorized and re-structured for the population of an itinerary database which is subsequently searched by a user rather than used in the formation of the search query itself.
Relevant prior art, Renaudie (US 20150317569) discloses the receipt of an image or scene, extraction of visual elements and retrieval of search results relevant to the associated query.
Relevant prior art, Yang (US20170132535), discloses detection of data cards with travel information that is used to form a purchasable itinerary.
Relevant prior art, Garman (US7979457), discloses entry of itinerary information via a website and the subsequent identification of the most relevant travel suppliers of purchasable itineraries..
Relevant prior art, English (US 20090150343), discloses a travel reservation search engine that constructs a first query from one or more constraints and, if determined necessary by the search engine, a second query is constructed from one or more constraints.
Relevant prior art, Garman (US7979457), discloses entry of itinerary information via a website and the subsequent identification of the most relevant travel suppliers of purchasable itineraries.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABBY J FLYNN whose telephone number is (571)272-9855. The examiner can normally be reached Monday - Friday 8:30-5:00.
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, James Trammell can be reached at (571) 272-6712. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABBY J FLYNN/ Primary Patent Examiner, Art Unit 3663