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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/26/2026 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 12–17 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to a judicial exception, namely an abstract idea, without integrating the judicial exception into a practical application and without reciting additional elements that amount to significantly more than the judicial exception.
The claims are evaluated under the Alice/Mayo framework, as reflected in MPEP § 2106 and the USPTO’s subject matter eligibility guidance.
Step 1: Statutory Category
Claims 12–17 fall within a statutory category.
Independent claim 12 recites an “information processing device” comprising a memory, a clock, a first processor, and a communication unit. Accordingly, claim 12 falls within the statutory category of a machine.
Claim 17 recites a system comprising the information processing device of claim 12 and a mobile terminal including a display and a second processor. Because the claimed system comprises tangible apparatus components, claim 17 also falls within the statutory category of a machine.
Dependent claims 13–16 depend from claim 12 and likewise fall within the statutory category of a machine.
Accordingly, claims 12–17 satisfy Step 1.
Step 2A, Prong 1: The Claims Recite a Judicial Exception
Claim 12 recites a judicial exception, namely an abstract idea. The abstract idea may be characterized as:
collecting user location, travel, time, and point-of-interest information, determining whether a point of interest should be presented to the user, and selectively providing or suppressing the notification based on that determination.
This characterization captures the focus of the claim without merely repeating the claim language.
Claim 12 recites, at a high level, storing spot information, map information, and user availability/no-notification information; acquiring location and speed information from a mobile terminal; determining a user’s transport mode; generating a virtual area; selecting spots located within that virtual area; computing arrival times; comparing the computed arrival times with opening hours and user availability/no-notification periods; and transmitting or suppressing a notification based on the result of those determinations.
These limitations fall within recognized categories of abstract ideas.
A. Certain Methods of Organizing Human Activity
Claim 12 recites managing a user’s travel, schedule, availability, notification preferences, and decisions regarding whether to visit nearby points of interest. The claim determines when a user should receive information about spots, such as locations having opening hours, based on the user’s travel mode, current location, speed, available time frame, no-notification time frame, and estimated arrival time.
This constitutes organizing human activity because the claim manages personal behavior, travel planning, and user interactions with points of interest by deciding whether and when to provide information to the user.
Dependent claim 13 further recites that the virtual-area size is designated by the user via the mobile terminal. This is a user preference for controlling the scope of recommendations.
Dependent claim 14 merely identifies categories of spots, including restaurants, retail stores, and tourist facilities, which are examples of places a user may choose to visit.
Dependent claim 15 recites that the no-notification time frame includes a commuting time period from Monday to Friday, which is a scheduling rule for suppressing notifications during a user’s routine travel period.
Dependent claim 16 recites determining the no-notification time frame based on historical data indicating dates and times at which the user stopped by spots. This likewise concerns learning or determining a user’s personal schedule or notification preference.
Accordingly, the claims recite managing personal behavior, schedule, travel, and notification preferences, which is a certain method of organizing human activity.
B. Mathematical Concepts
Claim 12 also recites mathematical calculations and relationships. For example, claim 12 recites generating a virtual area on a map, making the size of the virtual area differ for each category of spots, increasing the radius of the virtual area with traveling speed in train mode, computing a first arrival time by summing a time to a predicted next train stop and a walking time from the predicted next stop to the extracted spot, and computing a second arrival time based on opening hours and a predetermined stay time.
These limitations involve mathematical relationships and calculations used to determine whether the user can arrive at a spot within the required time period. The calculations are part of the abstract determination of whether to transmit or suppress a point-of-interest notification.
Accordingly, claim 12 recites mathematical concepts.
C. Mental Processes – Alternative/Supporting Basis
To the extent the claim recites observing information, evaluating conditions, comparing times, determining whether a condition is satisfied, and deciding whether to provide or suppress a notification, the claim also recites mental-process-type activity.
The Examiner recognizes that certain implementation details, such as real-time mobile-terminal location acquisition, route searching, and periodic updating, may involve computer-based processing that is not practically performed entirely in the human mind. Accordingly, the rejection does not rely solely on the mental-process grouping.
However, the presence of computer-executed data gathering, calculation, and repeated processing does not remove the claim from the abstract-idea category, where the focus of the claim remains collecting information, analyzing the information, and presenting or withholding information based on the analysis. See Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1353–56 (Fed. Cir. 2016). The claim’s route, location, speed, virtual area, and timing limitations define the information used and the rules for deciding whether to notify the user; they do not, at Step 2A, Prong 1, transform the underlying organizing human activity and mathematical concepts into non-abstract subject matter.
Therefore, claims 12–17 recite a judicial exception under Step 2A, Prong 1.
Step 2A, Prong 2: The Claims Do Not Integrate the Judicial Exception into a Practical Application
The claims are next evaluated to determine whether the judicial exception is integrated into a practical application.
Claim 12 recites the following additional elements beyond the abstract idea:
an information processing device;
a memory;
a clock;
a first processor;
a communication unit;
a mobile terminal from which location and speed information are acquired; and
transmission of a notification to the mobile terminal.
These additional elements do not integrate the abstract idea into a practical application.
The memory merely stores information used in the abstract analysis, including spot information, map information, and user information. The clock merely supplies the current time used in the claimed timing comparison. The first processor merely performs the claimed information analysis, mathematical calculations, route-search-related processing, comparison, and notification decision. The communication unit merely receives user/mobile-terminal information and transmits the resulting notification. The mobile terminal merely supplies location/speed information and receives the notification.
The claim does not recite an improvement to the operation of the processor, memory, communication unit, mobile terminal, display, map database, route-search technology, GPS/location-detection technology, wireless communication technology, or machine-learning technology. Instead, the claim uses generic information-processing components as tools to perform the abstract notification-selection process.
The claim’s virtual-area limitations do not integrate the abstract idea into a practical application. The limitations requiring the virtual area to differ by spot category, be centered on a predicted next train stop in train mode, and have a radius that increases with traveling speed merely refine the abstract criteria used to determine which spot information is relevant to the user. These limitations improve the relevance of the selected information, not the functioning of the underlying computer or mobile-device technology.
The claim’s extraction limitation likewise does not integrate the judicial exception into a practical application. Extracting only a spot located in the virtual area and excluding spots outside the virtual area from further computations merely narrows the dataset used in the abstract recommendation process. The claim does not recite a particular improved data structure, database indexing scheme, memory-management technique, search-engine architecture, routing-engine improvement, or other technical mechanism that improves computer functionality.
The claim’s arrival-time limitations also fail to integrate the abstract idea into a practical application. Computing a first arrival time by route searching constrained by transport mode, including summing time to a predicted next train stop and walking time from the predicted next stop to the extracted spot, and computing a second arrival time based on opening hours and a predetermined stay time, are mathematical and logical determinations used to decide whether a notification should be transmitted. These limitations improve the informational decision rule, not the technology used to perform the rule.
The claim’s notification limitation does not integrate the abstract idea into a practical application. Transmitting a notification including opening hours only when the current time and arrival-time conditions are satisfied, and otherwise suppressing the notification, is merely the output of the abstract analysis. Presenting the result of an abstract determination is insignificant post-solution activity and does not constitute a technological improvement.
The claim’s periodic-updating limitation does not change the analysis. Periodically updating the virtual area responsive to motion of the mobile terminal and repeating the extraction, computation, determination, and notification operations merely repeats the same abstract analysis as the user moves. The claim does not recite an improved motion-tracking technique, improved sensor arrangement, improved location-detection algorithm, improved mobile-device architecture, or improved communication protocol.
Applicant may argue that the claim improves location-based notification technology by dynamically adapting the virtual-area geometry to travel mode, speed, spot category, and predicted train-stop information. The Examiner respectfully disagrees.
The identified improvement is an improvement in the relevance, timing, and usefulness of the information delivered to the user, not an improvement in the underlying technology. The claimed processor, memory, communication unit, mobile terminal, map information, and display operate in their ordinary capacities. The claim does not recite a new computer architecture, new memory structure, new database structure, new signal-processing technique, new route-search algorithm, new wireless communication protocol, or new display interface.
This case is distinguishable from Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), where the claims were directed to a specific self-referential data table that improved the way a computer stored and retrieved data. Here, the claims do not recite a new data structure or a new way for the computer to store or retrieve data. The virtual area and arrival-time rules merely determine what information should be selected and when that information should be transmitted.
This case is also distinguishable from McRO, Inc. v. Bandai Namco Games America Inc., 837 F.3d 1299 (Fed. Cir. 2016), where the claimed rules improved a specific technological process for automated animation. Here, the claimed rules do not improve a technological process. They merely define criteria for selecting and suppressing point-of-interest notifications.
This case is further distinguishable from Core Wireless Licensing S.A.R.L. v. LG Electronics, Inc., 880 F.3d 1356 (Fed. Cir. 2018), where the claims were directed to a specific improved user interface. Here, claim 17 merely recites displaying a message corresponding to the notification. The claim does not recite a specific interface layout, interface architecture, or display mechanism that improves the operation of the mobile terminal.
Accordingly, the claim as a whole does not integrate the judicial exception into a practical application.
Dependent claim 13 does not add a practical application because allowing the user to designate the size of the virtual area merely adds user customization of the abstract recommendation rule.
Dependent claim 14 does not add a practical application because identifying restaurants, retail stores, and tourist facilities merely limits the informational content or field of use of the spot information.
Dependent claim 15 does not add a practical application because specifying a Monday-to-Friday commuting period merely recites a scheduling rule for suppressing notifications during a user’s routine travel period.
Dependent claim 16 does not add a practical application because determining the no-notification time frame “via a machine learning” using stored stop-history data merely applies a generic analytical tool to infer a user’s notification preference. The claim does not recite a particular machine-learning model, training method, feature-engineering process, loss function, model architecture, inference pipeline, hardware accelerator, or improvement to machine-learning technology.
Claim 17 does not add a practical application because it merely recites a mobile terminal having a display and a processor configured to display a message corresponding to the notification. Displaying the result of the abstract analysis does not improve display technology or mobile-terminal technology.
Therefore, claims 12–17 do not integrate the judicial exception into a practical application under Step 2A, Prong 2.
Step 2B: The Claims Do Not Recite Significantly More Than the Judicial Exception
Because claims 12–17 are directed to a judicial exception, the claims are evaluated under Step 2B to determine whether the additional elements, individually or as an ordered combination, amount to significantly more than the judicial exception.
The claims do not recite an inventive concept.
The additional elements in claim 12 are generic computer and communication components performing generic computer functions:
the memory stores information;
the clock provides the current time;
the processor processes information, performs calculations, compares values, and makes a determination;
the communication unit receives information and transmits information; and
the mobile terminal supplies location/speed information and receives a notification.
These functions are generic computer, communication, and display functions. The claim does not recite any unconventional hardware structure, specialized processor configuration, improved communication architecture, improved map database, improved route-search engine, improved location-detection system, improved display, or improved machine-learning technology.
The Examiner’s finding that these additional elements are well-understood, routine, and conventional is supported by the judicial decisions recognizing that generic computer components performing generic functions such as storing, receiving, processing, analyzing, transmitting, and displaying information do not provide an inventive concept. See Alice Corp. v. CLS Bank Int’l, 573 U.S. 208, 221–26 (2014); Electric Power Group, 830 F.3d at 1355–56; FairWarning IP, LLC v. Iatric Systems, Inc., 839 F.3d 1089, 1095–96 (Fed. Cir. 2016); Affinity Labs of Texas, LLC v. DIRECTV, LLC, 838 F.3d 1253, 1262–63 (Fed. Cir. 2016); Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370–71 (Fed. Cir. 2015).
To the extent necessary, the Examiner also takes official notice that generic processors, memories, clocks, communication units, mobile terminals, and displays performing their ordinary functions of storing information, tracking time, processing information, communicating data, and displaying messages were well-understood, routine, and conventional in the information-processing and mobile-device arts at the time of the invention. This official notice is limited to the generic nature of the claimed hardware and its ordinary functions, not to the patentability of the claimed subject matter as a whole.
The ordered combination also does not amount to significantly more. As an ordered combination, claim 12 merely performs the following sequence:
store spot, map, and user information;
receive current location and speed information;
determine a transport mode;
generate a virtual area;
select spots within the virtual area;
compute arrival-time information;
determine whether current time and arrival-time conditions are satisfied;
transmit or suppress a notification; and
periodically repeat the same process as the mobile terminal moves.
This ordered combination is the abstract idea itself implemented using generic computer and communication components. The claim does not recite a non-conventional arrangement of hardware components or a technical improvement arising from the ordered combination.
Dependent claim 13 does not provide an inventive concept because user designation of the virtual-area size is merely a user preference applied to the abstract recommendation process.
Dependent claim 14 does not provide an inventive concept because the recited spot categories — restaurant, retail store, and tourist facility — merely identify types of information to be processed.
Dependent claim 15 does not provide an inventive concept because the Monday-to-Friday commuting period is merely a conventional scheduling rule used to suppress notifications.
Dependent claim 16 does not provide an inventive concept because it recites machine learning only at a high level of generality. The claim does not specify any particular machine-learning model, training procedure, feature representation, optimization technique, model architecture, or technical improvement to machine-learning technology. Rather, the claim merely applies machine learning as a generic analytical tool to determine a user’s no-notification time frame from historical stop-by data.
This is analogous to Recentive Analytics, Inc. v. Fox Corp., 134 F.4th 1205 (Fed. Cir. 2025), where the Federal Circuit held that applying generic machine-learning techniques to a new field or data environment does not supply patent eligibility absent an improvement to the machine-learning technology itself. Here, claim 16 does not improve machine learning; it merely uses machine learning to infer a notification-suppression time period.
Claim 17 does not provide an inventive concept because the mobile terminal, display, and second processor merely receive and display the notification generated by the abstract analysis. Displaying the result of an abstract determination is routine post-solution activity and does not transform the claim into patent-eligible subject matter.
Accordingly, claims 12–17, individually and as ordered combinations, do not recite additional elements amounting to significantly more than the judicial exception.
Examiner’s Conclusion
Claims 12–17 are rejected under 35 U.S.C. § 101 because they are directed to a judicial exception without integrating the exception into a practical application and without reciting an inventive concept.
The claims are directed to the abstract idea of collecting user location, travel, time, and point-of-interest information, determining whether a point of interest should be presented to the user, and selectively providing or suppressing the notification based on that determination.
The claims recite certain methods of organizing human activity because they manage user travel, scheduling, notification preferences, and decisions regarding whether to visit points of interest. The claims also recite mathematical concepts because they require virtual-area generation, speed-dependent radius determination, arrival-time computation, and timing comparisons. To the extent the claims recite observation, evaluation, comparison, and decision-making, those limitations further support treatment as mental-process-type activity, although the rejection does not depend solely on the mental-process grouping.
The claims do not integrate the abstract idea into a practical application because the claimed memory, clock, processor, communication unit, mobile terminal, and display merely perform generic computer, communication, and display functions. The claims do not improve computer technology, mobile-device technology, routing technology, GPS/location technology, map-database technology, communication technology, display technology, or machine-learning technology.
The claims also do not recite significantly more than the judicial exception because the additional elements, individually and in ordered combination, amount to generic computer implementation of the abstract notification-selection process.
Accordingly, claims 12–17 are patent-ineligible under 35 U.S.C. § 101.
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.
Claims 12-17 are rejected under U.S.C. 35 as being unpatentable over Botea et al. (US009541412B1), herein after will be referred to as Botea, in view of Akin (US 2014/0336925 A1), in view of Onishi et al. (US 20060241857 A1), herein after will be referred to as Onishi, in view of Bailey et al. (US 7212920 B1), herein after will be referred to as Bailey, in view of Li et al. (US20110238288A1), herein after will be referred to as Li, and in view of Panagiotakis et al. (The Tourist Trip Design Problem with POI Categories via an Expectation-Maximization Based Method), herein after will be referred to as Panagiotakis.
Regarding Claim 12,
Disclosure by Botea
Botea discloses:
• An information processing device
See at least:
“Further, in various examples the system may be in the form of one of: (a) a smart phone; (b) a tablet computer; (c) a netbook computer, and (d) a laptop computer.” (Botea, col. 5, ll. 4–8)
Rationale:
Botea expressly discloses a computer-based system implemented as a smartphone, tablet computer, netbook computer, or laptop computer. Such a system processes information to compute and present a safe mobility area. Therefore, Botea discloses an information processing device.
• configured to communicate,
See at least:
“In one example, communication between and among the various components of FIG. 4 may be bi-directional. In another example, the communication may be carried out via the Internet, an intranet, a local area network, a wide area network and/or any other desired communication channel(s).” (Botea, col. 5, ll. 9–15)
o See also:
“may be offered as a service on the cloud and/or on client apps on smart phones/tablets.” (Botea, col. 6, ll. 57–60)
Rationale:
Botea expressly discloses bidirectional communication through network communication channels and deployment through cloud services and client applications. Thus, Botea discloses that the information processing device is configured to communicate. The specific communication endpoint, namely a mobile terminal of a user, is completed by Akin below.
• the information processing device comprising:
See at least:
“Referring now to FIG. 5, this figure shows a hardware configuration of computing system 500...” (Botea, col. 5, ll. 18–20)
Rationale:
Botea expressly discloses a computing-system hardware configuration, thereby disclosing an information processing device comprising hardware components.
• a memory
See at least:
“random access memory (RAM) 514, read-only memory (ROM) 516...” (Botea, col. 5, ll. 23–25)
Rationale:
Botea expressly discloses RAM and ROM, which correspond to memory.
• storing
See at least:
“a memory... storing computer readable instructions...” (Botea, col. 4, ll. 47–55)
Rationale:
Botea expressly discloses memory storing computer-readable instructions.
• (i) spot information
See at least:
“an identification of a plurality of points of interest on the map...” (Botea, col. 3, ll. 48–52)
Rationale:
Botea’s points of interest correspond to the claimed spots, and the identification of POIs corresponds to spot information.
• for a plurality of spots,
See at least:
“a plurality of points of interest on the map...” (Botea, col. 3, ll. 48–52)
Rationale:
Botea expressly discloses multiple points of interest, corresponding to a plurality of spots.
• the spot information
See at least:
“one or several target locations (POIs) on the map...” (Botea, col. 6, l. 66–col. 7, l. 4)
Rationale:
Botea discloses POI/target-location information used by the safe mobility-area mechanism. This corresponds to spot information.
• for each spot
See at least:
“for each point of interest... a maximum visitation time interval...” (Botea, col. 3, ll. 56–65)
Rationale:
Botea performs POI-specific timing computations for each point of interest. Therefore, Botea discloses spot information for each spot.
• including a location
See at least:
“points of interest on the map” and “current user location.” (Botea, col. 3, ll. 48–57)
Rationale:
Botea’s POIs are located on an electronic map and are used in travel-time calculations from the current user location. Therefore, the POI information necessarily includes location information.
• and opening hours;
See at least:
“POI opening hours.” (Botea, col. 7, ll. 1–6)
Rationale:
Botea expressly discloses POI opening hours.
• (ii) map information
See at least:
“obtaining... (a) an electronic map...” (Botea, col. 3, ll. 48–50)
Rationale:
Botea expressly discloses electronic map information.
• including roads,
See at least:
“current travel time between locations by road...” (Botea, col. 8, ll. 18–23)
Rationale:
Botea expressly discloses road-based travel information, which requires map information including roads.
• train routes,
See at least:
“current travel time between locations by rail using a train...” (Botea, col. 8, ll. 23–25)
Rationale:
Botea expressly discloses rail/train travel information, corresponding to train routes.
• and bus routes
See at least:
“current travel time between locations by road using a bus...” (Botea, col. 8, ll. 21–24)
Rationale:
Botea expressly discloses bus travel information, corresponding to bus routes.
• (iii) user information
See at least:
“one or more user preferences...” (Botea, col. 7, ll. 6–9)
Rationale:
Botea expressly discloses user preference information. This corresponds to user information stored or used by the information processing device.
• indicating
See at least:
“one or more user preferences (e.g., with respect to travel, transport... points of interest).” (Botea, col. 7, ll. 6–9)
Rationale:
Botea’s user preferences indicate information about travel, transport, and POIs.
• (a) an available time frame
See at least:
“what target locations can be visited, and for how long... without jeopardizing the arrival time at the final destination.” (Botea, col. 7, ll. 18–24)
Rationale:
Botea determines the time interval during which target locations can be visited before the acceptable final-destination arrival time. This corresponds to an available time frame.
• in which the user is available
See at least:
“can be visited by the user, and for how long...” (Botea, col. 3, ll. 58–65)
Rationale:
Botea determines the time during which the user can visit POIs without missing the acceptable final-destination arrival time. This corresponds to the user being available.
• to visit one or more of the plurality of spots
See at least:
“wants to visit several points of interest...” (Botea, col. 5, ll. 38–45)
Rationale:
Botea expressly discloses that the user wants to visit several POIs, corresponding to visiting one or more of the plurality of spots.
• a clock; and
See at least:
“obtaining... (f) a current time...” (Botea, col. 3, ll. 54–57)
Rationale:
Botea implicitly discloses a clock because a processor that obtains and updates based on current time necessarily relies on a system clock or equivalent time-keeping component. This is treated as implicit disclosure, not merely as an obvious design choice.
• a first processor
See at least:
“at least one processor or central processing unit (CPU) 511.” (Botea, col. 5, ll. 20–24)
Rationale:
Botea expressly discloses a processor.
• coupled to a communication unit,
See at least:
“communications adapter 534 for connecting the system 500 to a data processing network...” (Botea, col. 5, ll. 31–35)
Rationale:
Botea discloses a processor-based computing system including a communications adapter. The communications adapter corresponds to the communication unit.
• and configured to:
See at least:
“computer readable instructions that, when executed by the processor, implement...” (Botea, col. 4, ll. 47–55)
Rationale:
Botea discloses processor-executed instructions that configure the processor to perform the recited operations.
• (C) generate a virtual area
See at least:
“drawing a ‘safe’ area...” (Botea, col. 5, ll. 46–51)
Rationale:
Botea’s safe mobility area corresponds to the claimed virtual area.
• on a map
See at least:
“on an electronic map of a city...” (Botea, col. 5, ll. 46–51)
Rationale:
Botea expressly discloses generating the safe area on a map.
• and the current location information,
See at least:
“obtaining... (g) a current user location...” (Botea, col. 3, ll. 54–57)
Rationale:
Botea expressly discloses current user location as an input used in determining the safe mobility area.
• D) extract only a spot
See at least:
“highlighting points of interest inside the safe area...” (Botea, col. 5, ll. 54–56)
Rationale:
Botea identifies POIs inside the safe area. This corresponds to extracting a spot.
• located in the virtual area
See at least:
“points of interest inside the safe area...” (Botea, col. 5, ll. 54–56)
Rationale:
Botea limits the highlighted or identified POIs to those inside the safe area, corresponding to a spot located in the virtual area.
• from the spot information
See at least:
“an identification of a plurality of points of interest on the map...” (Botea, col. 3, ll. 48–52)
Rationale:
The identified POIs are selected from the POI information obtained by Botea.
• of each spot of the plurality of spots
See at least:
“which of the plurality of points of interest on the map can be visited...” (Botea, col. 3, ll. 58–65)
Rationale:
Botea evaluates the plurality of POIs and determines which can be visited. This corresponds to evaluating each spot of the plurality of spots.
• (E) compute a first arrival time
See at least:
“current time plus the time to travel from the current position to that point of interest.” (Botea, col. 3, ll. 60–64)
Rationale:
Botea computes the time at which the user reaches the POI by adding travel time to current time. This corresponds to the first arrival time.
• at which the user is expected to arrive at the extracted spot
See at least:
“time to travel from the current position to that point of interest.” (Botea, col. 3, ll. 60–64)
Rationale:
Botea’s travel-time computation produces an expected arrival time at the POI, corresponding to the extracted spot.
• by performing a route search
See at least:
“may keep track of possible journey plans...” (Botea, col. 5, ll. 50–54)
Rationale:
Botea’s use of possible journey plans over transportation-network information renders route searching on the map information obvious to a PHOSITA.
• on the map information
See at least:
“electronic map” and “transportation network.” (Botea, col. 3, ll. 48–57)
Rationale:
Botea’s journey planning uses map and transportation-network information.
• (G) determine,
See at least:
“determining by the processor...” (Botea, col. 3, ll. 58–65)
Rationale:
Botea expressly discloses processor determinations relating to POI visitability and timing.
• based on the clock,
See at least:
“obtaining... a current time...” (Botea, col. 3, ll. 54–57)
Rationale:
The determination is based on current time obtained from the implicitly disclosed clock.
• whether a current time
See at least:
“current time.” (Botea, col. 3, ll. 54–57)
Rationale:
Botea expressly discloses current time.
• is within the available time frame
See at least:
“what target locations can be visited, and for how long...” (Botea, col. 7, ll. 18–24)
Rationale:
Botea determines whether time remains available for POI visitation before the acceptable final-destination arrival time.
• (I periodically update the virtual area
See at least:
“as the current time and/or the current location changes, the safe mobility area changes.” (Botea, col. 4, ll. 17–22)
Rationale:
Botea expressly discloses dynamic updating of the safe mobility area, corresponding to periodically updating the virtual area.
• and repeat operations (D) through (H)
See at least:
“as the current time and/or the current location changes... the maximum visitation time interval for each point of interest changes...” (Botea, col. 4, ll. 17–22)
Rationale:
Because Botea dynamically recomputes the safe mobility area and POI visitation intervals as time/location change, repeating extraction, arrival-time computation, output-condition determination, and notification/output operations would have been obvious. This follows from the dynamic nature of Botea’s POI visitability computation.
• while the current time remains within the available time frame.
See at least:
“what target locations can be visited, and for how long...” (Botea, col. 7, ll. 18–24)
Rationale:
Botea’s repeated computation is meaningful while available time remains before the acceptable final-destination arrival time.
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• communicate with a mobile terminal• of a user,• each with stop points; and• and (b) a no-notification time frame• in which output of the spot information• to the mobile terminal• is suppressed;• (A) acquire• from the mobile terminal• (i) current location information• indicating a current location• of the mobile terminal• and (ii) speed information• indicating a traveling speed• of the mobile terminal;• (B) determine a transport mode• of the user• based on at least the speed information• and the map information,• the transport mode• including at least a train mode• and a walking mode;• based on the transport mode• wherein, a size of the virtual area• differs for each category of the plurality of spots,• and in the train mode,• the virtual area is centered• on a predicted next stop• of a train route• and has a radius• that increases with the traveling speed;• and exclude any spot outside the virtual area• from further computations;• constrained by the determined transport mode,• including, in the train mode,• summing i) a time• to the predicted next stop• and (ii) a walking time• from the predicted next stop• to the extracted spot• along the roads;• (F) compute a second arrival time• for the extracted spot• based on the opening hours• of the extracted spot• and a predetermined time• required for the user• to look around the extracted spot;• the second arrival time• being defined as an arrival time• that falls within the operating hours• while allowing the predetermined stay time• required for the user;• and not within the no-notification time frame;• (H) transmit• to the mobile terminal• a notification• including at least the opening hours of the extracted spot• only in a case where• (i) the current time• is within the available time frame• and not within the no-notification time frame• and (i) the first arrival time• is earlier than the second arrival time,• and otherwise suppress output of the notification; and• responsive to motion of the mobile terminal• according to the transport mode
Disclosure by Akin
Akin discloses:
• communicate with a mobile terminal
See at least:
“The example network system 100 may facilitate the exchange of data between the mobile device 110 and the map icon display system 130.” (Akin, 0019)
Rationale:
Akin expressly discloses communication with a mobile device. The mobile device corresponds to the claimed mobile terminal.
• of a user,
See at least:
“the mobile device 110 (or, user associated with the mobile device 110)...” (Akin, 0019)
Rationale:
Akin expressly discloses that the mobile device is associated with a user.
• (A) acquire
See at least:
“the movement module 210 may access information...” (Akin, 0022)
Rationale:
Akin discloses acquiring or accessing movement information.
• from the mobile terminal
See at least:
“from the GPS component 115 of the mobile device 110...” (Akin, 0022)
Rationale:
Akin expressly discloses acquiring information from the mobile device.
• (i) current location information
See at least:
“information identifying a geographic location of the mobile device 110...” (Akin, 0022)
Rationale:
Akin discloses geographic-location information of the mobile device.
• indicating a current location
See at least:
“current geographic location of the mobile device...” (Akin, 0043)
Rationale:
Akin’s geographic-location information indicates the current location.
• of the mobile terminal
See at least:
“geographic location of the mobile device 110.” (Akin, 0022)
Rationale:
Akin discloses the location of the mobile terminal.
• and (ii) speed information
See at least:
“information identifying a speed traveled or currently being traveled by the mobile device 110...” (Akin, 0022)
Rationale:
Akin expressly discloses speed information.
• indicating a traveling speed
See at least:
“speed traveled or currently being traveled...” (Akin, 0022)
Rationale:
Akin’s speed information indicates traveling speed.
• of the mobile terminal;
See at least:
“by the mobile device 110.” (Akin, 0022)
Rationale:
The speed is the traveling speed of the mobile device.
• (B) determine a transport mode
See at least:
“determine a mode of travel of the mobile device 110.” (Akin, 0023)
Rationale:
Akin expressly discloses determining a mode of travel, corresponding to a transport mode.
• of the user
See at least:
“a user associated with the mobile device 110 is travelling via a Subway train.” (Akin, 0043)
Rationale:
Akin determines the travel mode of the user associated with the mobile device.
• based on at least the speed information
See at least:
“determine the mode of travel based on the identified rate of speed...” (Akin, 0025)
Rationale:
Akin expressly uses speed or rate of speed to determine travel mode.
• and the map information,
See at least:
“compare current movement information... to geo-location information received from the geographic information system 135...” (Akin, 0040)
Rationale:
Akin compares current movement information to GIS/geographic information. The GIS information corresponds to map information used to determine the transport mode.
• the transport mode
See at least:
“mode of travel...” (Akin, 0023)
Rationale:
Akin expressly discloses the transport mode.
• including at least a train mode
See at least:
“public transportation mode of travel... Subway, bus, train...” (Akin, 0023)
Rationale:
Akin expressly discloses train/subway travel mode.
• and a walking mode;
See at least:
“pedestrian mode of travel (e.g., walking...).” (Akin, 0023)
Rationale:
Akin expressly discloses walking mode.
• based on the transport mode
See at least:
“cause an icon to be displayed... based on the determined mode of travel.” (Akin, 0026)
Rationale:
Akin teaches using the determined transport mode to control map-based output. In the combined system, Botea already generates the safe mobility area using transportation-network information, while Akin supplies the detected mode. Therefore, it would have been obvious to generate Botea’s virtual/safe area based on the transport mode because the reachable area differs depending on whether the user is walking, riding a train, or using another mode.
• responsive to motion of the mobile terminal
See at least:
“access information identifying a movement of a mobile device...” (Akin, 0038)
Rationale:
Akin expressly discloses using motion of the mobile terminal.
• according to the transport mode
See at least:
“determine a mode of travel for the mobile device...” (Akin, 0039)
Rationale:
Akin ties mobile-device motion to transport-mode determination. In combination with Botea’s dynamic safe-area update, the virtual area is updated according to the transport mode.
Motivation to Combine Botea and Akin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea and Akin before them, to modify Botea’s safe mobility-area system to acquire current location, speed, and motion information from a user’s mobile terminal and determine the user’s transport mode using Akin’s GPS/GIS-based travel-mode determination. Botea already requires current location and transportation-network information to compute the safe mobility area, and Akin supplies a known mobile-device mechanism for providing that information. The combination would predictably improve Botea’s safe mobility computation by adapting the virtual area to the user’s actual movement and transport mode.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea and Akin
After combining the teachings of Botea and Akin, the following claim limitations remain:
• each with stop points; • and (b) a no-notification time frame• in which output of the spot information• to the mobile terminal• is suppressed;• wherein, a size of the virtual area• differs for each category of the plurality of spots,• and in the train mode,• the virtual area is centered• on a predicted next stop• of a train route• and has a radius• that increases with the traveling speed;• and exclude any spot outside the virtual area• from further computations;• constrained by the determined transport mode,• including, in the train mode,• summing i) a time• to the predicted next stop• and (ii) a walking time• from the predicted next stop• to the extracted spot• along the roads;• (F) compute a second arrival time• for the extracted spot• based on the opening hours• of the extracted spot• and a predetermined time• required for the user• to look around the extracted spot;• the second arrival time• being defined as an arrival time• that falls within the operating hours• while allowing the predetermined stay time• required for the user;• and not within the no-notification time frame;• (H) transmit• to the mobile terminal• a notification• including at least the opening hours of the extracted spot• only in a case where• (i) the current time• is within the available time frame• and not within the no-notification time frame• and (i) the first arrival time• is earlier than the second arrival time,• and otherwise suppress output of the notification;
Disclosure by Onishi
Onishi renders obvious:
• each with stop points;
See at least:
“road network data 36 equipped with map data for route searching” and “traffic network data 37 for searching route sections applicable to transportation facilities.” (Onishi, 0080)
o See also:
“each station (each stop in the case of a bus) provided on each traffic route A, B, and C is designated as a node, and a link is used to connect the nodes.” (Onishi, 0092)
Rationale:
Onishi expressly discloses traffic network data for transportation-facility route searching and expressly states that each station or bus stop on a traffic route is designated as a node. Therefore, Onishi discloses train routes and bus routes each with stop points.
• and in the train mode,
See at least:
“in case of transportation facilities, station names and flight names are accumulated in the traffic network data 37...” (Onishi, 0091)
Rationale:
Onishi expressly discloses transportation-facility route data including station information. When combined with Akin’s express train-mode determination, Onishi supplies the train-mode route-search framework.
• the virtual area is centered
See at least:
“all kinds of transportation facilities after the departure time... are sequentially selected as routes at departure time.” (Onishi, 0096)
o See also:
“the current location of the navigation terminal 20... as a departure location...” (Onishi, 0098)
Rationale:
Onishi expressly discloses current-location-based route searching using transportation-facility routes, timetables, and station/stop nodes. In the combined Botea-Akin-Onishi system, the broadest reasonable interpretation of “predicted next stop” includes a system-determined next station node on the user’s train route determined from current train-mode position and timetable/route data. A PHOSITA would have centered the train-mode virtual area on that next actionable stop because, while aboard a train, the user cannot depart the train and begin walking to a POI until reaching a stop. The next stop is therefore the first actionable location for extracting visitable nearby POIs. Centering on the current in-train GPS position would be less useful because it may correspond to a rail segment where the user cannot access surrounding POIs. This supplies the technical reason for centering the area on the next stop rather than the current position.
• on a predicted next stop
See at least:
“all kinds of transportation facilities after the departure time... are sequentially selected...” (Onishi, 0096)
o See also:
“the current location of the navigation terminal 20... as a departure location...” (Onishi, 0098)
Rationale:
Onishi’s timetable and stop-node data allow a system to determine the next station/stop on a transportation route from the current route position and departure/arrival timing. In the combined system, Akin determines that the user is in train mode and provides mobile-device movement/location, while Onishi provides the station-node/timetable framework. Under BRI, the “predicted next stop” is reasonably met by a system-determined upcoming station node, including a schedule-based next stop. The prediction is not merely a user-entered destination; it is the system’s determination of the upcoming stop on the route from current mobile/location and transportation-route information.
• of a train route
See at least:
“each station... provided on each traffic route A, B, and C is designated as a node...” (Onishi, 0092)
Rationale:
Onishi expressly discloses station nodes on traffic routes. In the train-mode implementation of the combined system, those station nodes correspond to stops of a train route.
• constrained by the determined transport mode,
See at least:
“road network data 36 equipped with map data for route searching.” (Onishi, 0080)
o See also:
“traffic network data 37 for searching route sections applicable to transportation facilities.” (Onishi, 0080)
o See also:
“when a station near a destination location or departure location is searched and/or a walking route to the nearby station is searched...” (Onishi, 0083)
Rationale:
Onishi discloses separate data and route-search processes for road/walking routes and transportation-facility routes. In the combined system, Akin determines the user’s transport mode, and Onishi supplies the corresponding train or walking route-search data. Therefore, the route search is constrained by the determined transport mode.
• including, in the train mode,
See at least:
“in case of transportation facilities, station names and flight names are accumulated in the traffic network data 37...” (Onishi, 0091)
Rationale:
Onishi expressly supports route searching using station information for transportation facilities. In the combined system, this applies in train mode.
• summing i) a time
See at least:
“data regarding the time span of each route or the number of required transfer times are accumulated and provided for purposes of guiding users.” (Onishi, 0096)
Rationale:
Onishi discloses route time spans, which are used in route computation. Summing route-time components would have been a routine route-search calculation.
• to the predicted next stop
See at least:
“arrival time at a transfer node...” (Onishi, 0096)
o See also:
“the current location of the navigation terminal 20... as a departure location...” (Onishi, 0098)
Rationale:
Onishi’s transportation-facility route search uses departure time, route time spans, and arrival times at nodes. In the combined train-mode system, the predicted next stop corresponds to the next station/stop node determined from the user’s current train-mode position and timetable. Computing the time to that predicted next stop is a routine use of Onishi’s route-time and arrival-time data.
• and (ii) a walking time
See at least:
“when a station near a destination location or departure location is searched and/or a walking route to the nearby station is searched...” (Onishi, 0083)
Rationale:
Onishi expressly discloses walking-route searching.
• from the predicted next stop
See at least:
“route guide data including a station near the entry point G1... and a walking route from the nearby station to the entry point G1 are searched...” (Onishi, 0110)
Rationale:
In the combined system, the predicted next stop corresponds to the nearby station from which the user begins walking after disembarking.
• to the extracted spot
See at least:
“walking route from the nearby station to the entry point G1...” (Onishi, 0110)
Rationale:
In the combined system, the extracted spot is the POI destination reached by the walking route from the predicted next stop.
• along the roads;
See at least:
“road network data 36 equipped with map data for route searching.” (Onishi, 0080)
o See also:
“walking route to the nearby station is searched...” (Onishi, 0083)
Rationale:
Onishi’s walking-route search is performed using road-network data, corresponding to walking along roads.
Motivation to Combine Botea, Akin, and Onishi
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, and Onishi before them, to incorporate Onishi’s transportation-facility route network, train/bus stop-node data, timetable-based route timing, and walking-route searching into the Botea-Akin system. Botea already computes a safe area using transportation-network information; Akin determines the user’s train or walking mode from mobile-device motion and GIS data; and Onishi provides route-search implementation using train/bus station nodes, timetable data, and walking-route data. In train mode, a PHOSITA would have recognized that the next stop is the first actionable location at which the user can disembark and begin walking to a POI. Moreover, Akin’s system already continuously acquires mobile-device location and movement information in real time; applying Onishi’s station-node and timetable data to that continuously acquired location/movement stream to identify the next approaching station would have been an obvious real-time extension of Onishi’s route-node framework. This would have predictably allowed the combined system to determine the next actionable disembarkation point for POI extraction and pre-arrival notification in train mode.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea, Akin, and Onishi
After combining Botea, Akin, and Onishi, the following limitations remain:
• and (b) a no-notification time frame• in which output of the spot information• to the mobile terminal• is suppressed;• wherein, a size of the virtual area• differs for each category of the plurality of spots,• and has a radius• that increases with the traveling speed;• and exclude any spot outside the virtual area• from further computations;• (F) compute a second arrival time• for the extracted spot• based on the opening hours• of the extracted spot• and a predetermined time• required for the user• to look around the extracted spot;• the second arrival time• being defined as an arrival time• that falls within the operating hours• while allowing the predetermined stay time• required for the user;• and not within the no-notification time frame;• (H) transmit• to the mobile terminal• a notification• including at least the opening hours of the extracted spot• only in a case where• (i) the current time• is within the available time frame• and not within the no-notification time frame• and (i) the first arrival time• is earlier than the second arrival time,• and otherwise suppress output of the notification; and
Disclosure by Bailey
Bailey discloses:
• and has a radius
See at least:
“The data conversion module, designated generally as 18, converts an input vehicle speed signal to a distance range value.” (Bailey, col. 4, ll. 10–13)
Rationale:
Bailey’s distance range value corresponds to a radius/range of a moving-map area. In the combined system, this range corresponds to the radius of the virtual area.
• that increases with the traveling speed;
See at least:
“If the vehicle speed input signal is between the lower and upper speed limits, the Map Range (distance range value) is set equal to the vehicle speed multiplied by the Range Gain Factor...” (Bailey, col. 6, ll. 59–64)
Rationale:
Bailey expressly teaches that, when the speed input is between the lower and upper speed limits, the map range equals vehicle speed multiplied by the Range Gain Factor. Within that operative speed range, the distance range increases as speed increases. In the combined system, this teaches or renders obvious a virtual-area radius that increases with traveling speed, with conventional lower/upper bounds applied as implementation limits.
• and exclude any spot outside the virtual area
See at least:
“Separate those specific items within the geographical database which are within the determined Map Range (distance range value) of the current vehicle position, from those which are outside of the Map Range (distance range value).” (Bailey, col. 7, ll. 10–16)
Rationale:
Bailey expressly separates in-range items from out-of-range items. In the combined POI system, out-of-range spots correspond to spots outside the virtual area.
• from further computations;
See at least:
“Only these items will appear on the Moving-Map Display.” (Bailey, col. 7, ll. 10–16)
Rationale:
Bailey’s system filters items outside the Map Range before moving-map display processing, such that outside items are not processed through the later display-generation operation. Thus, computational exclusion is inherent in Bailey’s filtering process, not merely a downstream presentation choice. In the combined POI system, excluding out-of-area POIs from further arrival-time and notification computations would have been a predictable efficiency improvement because those POIs are not actionable within the current virtual area.
Motivation to Combine Botea, Akin, Onishi, and Bailey
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, and Bailey before them, to apply Bailey’s speed-dependent range control to the Botea-Akin-Onishi virtual/safe area. Botea generates a dynamic safe area, Akin supplies mobile speed and travel mode, Onishi supplies train/walking route computation, and Bailey teaches expanding map range with speed within an operative speed range and filtering out-of-range items before further display processing. The combination would predictably improve real-time POI relevance and computational efficiency.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea, Akin, Onishi, and Bailey
After combining Botea, Akin, Onishi, and Bailey, the following limitations remain:
• and (b) a no-notification time frame• in which output of the spot information• to the mobile terminal• is suppressed;• wherein, a size of the virtual area• differs for each category of the plurality of spots,• (F) compute a second arrival time• for the extracted spot• based on the opening hours• of the extracted spot• and a predetermined time• required for the user• to look around the extracted spot;• the second arrival time• being defined as an arrival time• that falls within the operating hours• while allowing the predetermined stay time• required for the user;• and not within the no-notification time frame;• (H) transmit• to the mobile terminal• a notification• including at least the opening hours of the extracted spot• only in a case where• (i) the current time• is within the available time frame• and not within the no-notification time frame• and (i) the first arrival time• is earlier than the second arrival time,• and otherwise suppress output of the notification;
Disclosure by Li
Li discloses or renders obvious:
• and (b) a no-notification time frame
See at least:
“The storage unit 504 can also store... messages, notifications, points of interest (POI), navigation routing entries, or any combination thereof.” (Li, 0062)
Rationale:
Li expressly discloses stored notifications and POI information. Li does not expressly use the words “no-notification time frame.” However, in the combined system, Botea already stores and uses user preference information, including an available-time constraint, and Akin supplies a mobile-terminal notification/output environment. A PHOSITA would have been motivated to store a paired user preference for a no-notification time frame in the same user-information structure because both the available time frame and the no-notification time frame are time-based user availability constraints controlling whether POI information should be output. This implements a predictable user-preference gate for mobile POI notifications.
• in which output of the spot information
See at least:
“If the candidate location cannot be reached before closing time... the navigation system 100 will not display it on the display interface.” (Li, 0047)
Rationale:
Li teaches suppressing POI output when output would be inappropriate because the POI cannot be reached before closing. Although Li’s suppression is feasibility-based, a PHOSITA implementing stored user preferences in the combined system would have applied the same output-control principle to a user-specified no-notification time frame, because both conditions determine whether spot information should be output to the user.
• to the mobile terminal
See at least:
“cause an icon to be displayed, via a mapping application supported by the mobile device...” (Akin, 0026)
Rationale:
Akin supplies the mobile-terminal output path. In the combined system, Li’s POI output and notification information would be transmitted or presented to the mobile terminal.
• is suppressed;
See at least:
“If the candidate location cannot be reached before closing time... the navigation system 100 will not display it on the display interface.” (Li, 0047)
Rationale:
Botea already discloses user preferences and time-based available-time constraints that govern whether POI information should be output to the user. Adding a paired no-notification time constraint to the same user-preference structure would have predictably suppressed POI output during user-specified quiet periods. Akin supplies the mobile-terminal output environment, and Li reinforces the general principle of conditionally suppressing user-facing POI output when output is not appropriate. Thus, suppressing spot-information output during a no-notification time frame would have been an obvious temporal-gating extension of Botea’s user-preference framework, implemented in Akin’s mobile-output environment and supported by Li’s conditional output-suppression logic.
• and not within the no-notification time frame;
See at least:
“current time 744” and “messages, notifications...” (Li, 0062, 0214)
Rationale:
Li discloses current-time-based POI evaluation and stored notifications. In the combined system, a PHOSITA would have checked the current time against the stored no-notification time frame before outputting mobile POI notifications. This is a predictable time-based user-preference gate, parallel to Botea’s available-time gate.
• (H) transmit
See at least:
“messages, notifications...” (Li, 0062)
Rationale:
Li discloses notification information. In the combined mobile system, transmitting such notification information to the mobile terminal would have been obvious.
• to the mobile terminal
See at least:
“mapping application supported by the mobile device.” (Akin, 0026)
Rationale:
Akin discloses output via a mobile-device mapping application, corresponding to transmission to the mobile terminal.
• a notification
See at least:
“messages, notifications...” (Li, 0062)
Rationale:
Li expressly discloses notifications.
• including at least the opening hours of the extracted spot
See at least:
“associated information including... an operating schedule...” (Li, 0122)
Rationale:
Li’s operating schedule corresponds to opening hours of the extracted spot. Including such operating schedule information in the notification would have been obvious because Li uses operating hours to determine valid arrival and POI desirability.
• only in a case where
See at least:
“If the candidate location cannot be reached before closing time... will not display it...” (Li, 0047)
Rationale:
Li discloses conditional POI output based on whether the POI can be reached at a valid time. This supports output only when specified conditions are met.
• (i) the current time
See at least:
“current time 744.” (Li, 0214)
Rationale:
Li expressly discloses current time.
• is within the available time frame
See at least:
Botea’s “what target locations can be visited, and for how long...” (Botea, col. 7, ll. 18–24) and Li’s “arrival time 926 can be based on the current time 744...” (Li, 0214)
Rationale:
Botea supplies the available time frame, and Li supplies current-time-based POI arrival feasibility. In combination, the system determines whether the current time is within the available time frame before outputting POI information.
• and not within the no-notification time frame
See at least:
“messages, notifications...” and “current time 744.” (Li, 0062, 0214)
Rationale:
Li discloses stored notifications and current time. In combination with Botea’s user preferences and Akin’s mobile-device output, a PHOSITA would have gated notifications by determining whether the current time is outside a stored no-notification interval. The reason is that POI notifications are user-facing, time-sensitive mobile outputs, and a stored quiet interval predictably prevents unwanted output during times when the user has indicated that spot information should be suppressed.
• and (i) the first arrival time
See at least:
“The arrival time 926 can indicate the time when the navigation system 700 will arrive at the first point of interest 214.” (Li, 0214)
Rationale:
Li expressly discloses first-arrival-time computation.
• is earlier than the second arrival time,
See at least:
“The valid arrival 752 can indicate the desirability of the first point of interest 214 based on an arrival at the first point of interest 214 during the operating hours 924...” (Li, 0212)
o See also:
“The valid arrival 752 can be calculated by comparing the operating hours 924 of the first point of interest 214 with the arrival time 926.” (Li, 0217)
Rationale:
Li teaches comparing arrival time with POI operating hours. Panagiotakis supplies the stay-time-adjusted second arrival time below. Thus, determining whether the first arrival time is earlier than the second arrival time is a predictable implementation of Li’s valid-arrival comparison with Panagiotakis’s latest permissible arrival calculation.
• and otherwise suppress output of the notification; and
See at least:
“will not display it on the display interface” and “eliminated those with a low ranking.” (Li, 0047–0048)
Rationale:
Li expressly suppresses POI output when validity conditions are not satisfied. Applying that suppression to notification output in the combined mobile system would have been obvious because both display output and notification output are user-facing POI outputs, and suppression prevents irrelevant or non-actionable alerts.
Motivation to Combine Botea, Akin, Onishi, Bailey, and Li
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, and Li before them, to incorporate Li’s notification storage, operating-schedule information, valid-arrival comparison, and output-suppression logic into the Botea-Akin-Onishi-Bailey safe-mobility POI system. Botea already uses user preferences and available-time constraints for POI recommendation, Akin supplies the mobile terminal and movement-based context, Onishi supplies route-search details for train/walking modes, and Bailey supplies speed-dependent area filtering. Li adds context-sensitive POI output and suppression. A PHOSITA would have implemented the no-notification time frame as a stored user preference paired with Botea’s available-time frame because both are user-specific temporal constraints governing whether POI spot information should be output.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea, Akin, Onishi, Bailey, and Li
After combining Botea, Akin, Onishi, Bailey, and Li, the following limitations remain:
• wherein, a size of the virtual area• differs for each category of the plurality of spots,• (F) compute a second arrival time• for the extracted spot• based on the opening hours• of the extracted spot• and a predetermined time• required for the user• to look around the extracted spot;• the second arrival time• being defined as an arrival time• that falls within the operating hours• while allowing the predetermined stay time• required for the user;
Disclosure by Panagiotakis
Panagiotakis discloses or renders obvious:
• wherein, a size of the virtual area
See at least:
“POIs are divided into categories...” and “taking into account... POIs category constraints and spatial constraints...” (Panagiotakis, p. 1)
Rationale:
Panagiotakis teaches POI categories, category constraints, and spatial constraints. In view of Bailey’s variable map range and Botea’s virtual/safe area, it would have been obvious to vary the virtual-area size according to category-specific POI constraints. The technical reason is that categories differ in expected density and user priority: common categories such as restaurants or gas stations may require only a smaller area to find sufficient candidates, while sparse, mandatory, or under-satisfied categories may require a larger area to locate enough relevant spots. This implements Panagiotakis’s category constraints using Bailey’s variable range within Botea’s safe-area framework.
• differs for each category of the plurality of spots,
See at least:
“minimum/maximum limits on the number of POIs belonging to each category.” (Panagiotakis, p. 1)
Rationale:
Panagiotakis expressly discloses category-specific limits. A PHOSITA would have varied the virtual area for each category to satisfy those category-specific limits while controlling computational burden and notification clutter. For example, if a required category is geographically sparse, a larger virtual area is predictably needed to identify enough candidate POIs; if a category is dense or already satisfied, a smaller virtual area predictably reduces unnecessary computations and user-facing alerts. Varying the search radius is a predictable location-based-service technique for satisfying category-count constraints because the number of available candidate POIs in a category depends directly on both category density and search-area size.
• (F) compute a second arrival time
See at least:
“POIs opening hours... user time budget... POIs travel times...” (Panagiotakis, Fig. 1 and p. 2)
Rationale:
Panagiotakis teaches itinerary feasibility using POI opening hours, travel times, and user time budget. Computing a latest permissible arrival time is a routine consequence of these time-window feasibility constraints.
• for the extracted spot
See at least:
“sequence of Points of Interest (POIs).” (Panagiotakis, p. 1)
Rationale:
The extracted spot corresponds to the POI being considered in the itinerary or recommendation.
• based on the opening hours
See at least:
“POIs opening hours...” (Panagiotakis, p. 1–2)
Rationale:
Panagiotakis expressly uses POI opening hours in determining feasible itineraries.
• of the extracted spot
See at least:
“POIs opening hours...” (Panagiotakis, p. 1–2)
Rationale:
The opening hours are associated with the POI being considered, which corresponds to the extracted spot.
• and a predetermined time
See at least:
“The size and the color of a POI correspond to the duration of the visit...” (Panagiotakis, p. 2)
Rationale:
Panagiotakis’s visit duration is a pre-specified per-POI input parameter used before the itinerary/notification feasibility computation. Therefore, it corresponds to a predetermined time, not a dynamically generated post-notification value.
• required for the user
See at least:
“personalized itinerary” and “user time budget.” (Panagiotakis, p. 1–2)
Rationale:
The visit duration is applied to the user’s itinerary and time-budget feasibility computation. Therefore, it is time required for the user.
• to look around the extracted spot;
See at least:
“duration of the visit.” (Panagiotakis, p. 2)
Rationale:
Panagiotakis’s visit duration encompasses time spent at the POI for the user’s activity at that spot. Under a broad but reasonable interpretation, “to look around” includes the user’s sightseeing, browsing, visiting, or otherwise spending time at the POI. Thus, the POI visit duration corresponds to the time required for the user to look around the extracted spot.
• the second arrival time
See at least:
“POIs opening hours... time windows...” (Panagiotakis, p. 2)
Rationale:
The second arrival time is the latest feasible arrival derived from the POI opening-hour window and visit duration.
• being defined as an arrival time
See at least:
“arrival/departure time at POI.” (Panagiotakis, Table 1)
Rationale:
Panagiotakis models arrival time at a POI. The claimed second arrival time is an arrival-time threshold derived from that model.
• that falls within the operating hours
See at least:
“POIs opening hours (i.e. time windows at the locations).” (Panagiotakis, p. 2)
Rationale:
Panagiotakis requires POI visits to satisfy opening-hour time windows, corresponding to an arrival time that falls within operating hours.
• while allowing the predetermined stay time
See at least:
“duration of the visit.” (Panagiotakis, p. 2)
Rationale:
A valid POI arrival must allow completion of the predetermined visit duration. Algebraically, where the POI closing time is C and the predetermined stay/visit duration is d, the latest permissible arrival time is C − d.
• required for the user;
See at least:
“user time budget” and “duration of the visit.” (Panagiotakis, p. 1–2)
Rationale:
The predetermined stay time is required for the user’s planned visit. Therefore, the second arrival time is defined as an arrival time that falls within operating hours while allowing the required stay time. The formula C − d directly gives the latest permissible arrival time satisfying those constraints.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to incorporate Panagiotakis’s POI-category constraints, POI opening-hour constraints, user-time-budget constraints, and predetermined visit-duration modeling into the Botea-Akin-Onishi-Bailey-Li system. Botea provides safe-area POI feasibility, Akin provides mobile-terminal speed/location and transport mode, Onishi provides train/walking route computation, Bailey provides speed-dependent area sizing and filtering, Li provides operating-hour valid-arrival and notification suppression, and Panagiotakis adds category and stay-duration itinerary constraints. The combination would predictably improve the system by ensuring that notifications are category-relevant, computationally efficient, within the user’s available time, outside a no-notification interval, and feasible before closing while allowing the required stay time.
Regarding Claim 13,
The combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis establishes the information processing device of Claim 12, which is the basis for Claim 13.
Disclosure by Botea
Botea discloses or renders obvious:
• Information processing device,
o See at least:
“Further, in various examples the system may be in the form of one of: (a) a smart phone; (b) a tablet computer; (c) a netbook computer, and (d) a laptop computer.” (Botea, col. 5, ll. 4–8)
o See also:
“Referring now to FIG. 5, this figure shows a hardware configuration of computing system 500...” (Botea, col. 5, ll. 18–20)
Rationale:
Botea expressly discloses an information processing device implemented as a processor-based computing system. The full information processing device according to Claim 12 is established by the parent-claim combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis. Therefore, Botea supplies the primary information-processing-device framework, while the complete Claim 12 device is supplied by the full reference combination.
• wherein the size of the virtual area
o See at least:
“As described herein, mechanisms are provided for computing and displaying a (maximized) safe mobility area (in terms of time). This safe mobility area may be an area inside which a user can act without jeopardizing a final goal specified by the user.” (Botea, col. 6, ll. 22–28)
o See also:
“the safe mobility area may be computed dynamically, such that the safe mobility area shrinks as time passes...” (Botea, col. 6, ll. 36–40)
Rationale:
Botea expressly discloses a safe mobility area, which corresponds to the claimed virtual area. Botea further discloses that the safe mobility area may shrink as time passes. A safe mobility area that can be computed, displayed, maximized, and dynamically shrunk necessarily has a size or extent. Therefore, Botea discloses the size of the virtual area.
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• is designated by the user
• via the mobile terminal.
Disclosure by Akin
Akin discloses or renders obvious:
• is designated by the user
o See at least:
“the mobile device 110 (or, user associated with the mobile device 110) may be traveling at a certain rate of speed and/or along a certain route...” (Akin, 0019)
o See also:
“The bus stop elements 657, 659 (and other elements described herein) may, for example, be user-selectable, and provide information about bus times, bus routes, and so on, when selected by the user.” (Akin, 0058)
Rationale:
Akin expressly discloses user-selectable map elements in a mobile-device mapping environment. Botea discloses that its safe mobility area is user-specific and depends on user-specified goals and user preferences, including travel, transport, and points-of-interest preferences. In the combined Botea-Akin system, it would have been obvious to allow the user to designate the size of the virtual area because virtual-area size controls the scope of map/POI information presented to the user, and user selection of map-related parameters through a mobile mapping interface was a predictable way to improve user control and personalization. This is a PHOSITA-obvious extension of Botea’s user-preference-driven safe-area computation implemented through Akin’s user-selectable mobile mapping interface.
• via the mobile terminal.
o See at least:
“The example network system 100 may facilitate the exchange of data between the mobile device 110 and the map icon display system 130.” (Akin, 0019)
o See also:
“cause an icon to be displayed, via a mapping application supported by the mobile device, that is based on the determined mode of travel.” (Akin, 0026)
o See also:
“FIG. 6A depicts a user interface 600 of the mobile device 110, which presents a walking icon 615 within a map 610 displayed by a mapping application 115 supported by the mobile device 110.” (Akin, 0054)
Rationale:
Akin expressly discloses a mobile device, data exchange between the mobile device and a map icon display system, a mapping application supported by the mobile device, and a user interface of the mobile device presenting map information. Therefore, Akin expressly discloses that user interaction with map-related information occurs via the mobile terminal. In the combined system, the user-designated virtual-area size would predictably be entered through Akin’s mobile-device mapping interface.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to further modify the Claim 12 information processing device established by Botea, Akin, Onishi, Bailey, Li, and Panagiotakis so that the size of the virtual area is designated by the user via the mobile terminal. Botea computes and displays a user-specific safe mobility area based on user goals, user preferences, current time, current location, POI information, and transportation-network information. Akin supplies the mobile terminal, mobile mapping application, data-exchange pathway, and user-selectable mobile interface through which the user interacts with map-related information. Onishi, Bailey, Li, and Panagiotakis remain part of the parent Claim 12 combination because they supply the train/stop route-search details, speed-dependent virtual-area radius/filtering, notification/output suppression and operating-schedule logic, and category/stay-time constraints required by Claim 12. Combining Akin’s mobile user interface with Botea’s user-preference-driven safe mobility area would have predictably allowed the user to designate the virtual-area size through the mobile terminal, improving user control over the scope of displayed or recommended POI information while preserving the full Claim 12 functionality supplied by the entire prior-art combination.
Incorporating Lorka’s recommendation, I revised the tourist facility mapping so it is no longer presented as an express “scenic viewpoint = tourist facility” BRI mapping. It is now framed as a PHOSITA-obvious POI category in view of Li’s POI taxonomy and the Claim 12 POI recommendation framework.
Regarding Claim 14,
The combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis establishes the information processing device of Claim 12, which is the basis for Claim 14.
Disclosure by Botea
Botea discloses:
• Information processing device,
o See at least:
“Further, in various examples the system may be in the form of one of: (a) a smart phone; (b) a tablet computer; (c) a netbook computer, and (d) a laptop computer.” (Botea, col. 5, ll. 4–8)
o See also:
“Referring now to FIG. 5, this figure shows a hardware configuration of computing system 500 according to an embodiment of the present invention. As seen, this hardware configuration has at least one processor or central processing unit (CPU) 511... random access memory (RAM) 514, read-only memory (ROM) 516... [and] a communications adapter 534 for connecting the system 500 to a data processing network, the Internet, an Intranet, a local area network (LAN), etc.” (Botea, col. 5, ll. 18–35)
Rationale:
Botea expressly discloses a processor-based information processing system having processor, memory, and communication hardware. The full information processing device according to Claim 12 is established by the parent-claim combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis. Therefore, Botea supplies the primary information-processing-device framework, while the complete Claim 12 device is supplied by the full reference combination.
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• wherein the category of the plurality of spots
• includes a restaurant,
• a retail store,
• and a tourist facility.
Disclosure by Li
Li discloses or renders obvious:
• wherein the category of the plurality of spots
o See at least:
“The first point of interest 214 can represent a named entity with an identifiable location. The first point of interest 214 can represent an entity such as a restaurant, business, School, Scenic viewpoint, object, coordinate, or any combination thereof. The first point of interest 214 can include associated information including a name, an operating schedule, a type, a facility, a resource, or any combination thereof.” (Li, 0122)
Rationale:
Li expressly discloses that a point of interest may include associated information including “a type” and “a facility.” A “type” of point of interest corresponds to a category of a spot because it classifies the POI by the kind of entity represented. Thus, Li discloses or at least renders obvious the category of the plurality of spots.
• includes a restaurant,
o See at least:
“The first point of interest 214 can represent an entity such as a restaurant, business, School, Scenic viewpoint, object, coordinate, or any combination thereof.” (Li, 0122)
o See also:
“In another example, the navigation system 700 can import the external data source 720 that includes the list of restaurants in the local area and their geographical coordinates.” (Li, 0125)
Rationale:
Li expressly discloses that a point of interest may represent a restaurant and further discloses importing a list of restaurants in the local area with geographical coordinates. Therefore, Li expressly discloses that the category of the plurality of spots includes a restaurant.
• a retail store,
o See at least:
“The first point of interest 214 can represent an entity such as a restaurant, business, School, Scenic viewpoint, object, coordinate, or any combination thereof.” (Li, 0122)
o See also:
“For example, in the situation where a convenience store has recently installed gasoline pumps, the user could select the first point of interest 214 that represents the convenience store...” (Li, 0126)
Rationale:
Li expressly discloses that a point of interest may represent a business and specifically gives a convenience store as an example of a point of interest. Under the broadest reasonable interpretation, a convenience store is a retail store because it is a store that sells goods to consumers. Therefore, Li expressly discloses or at least renders obvious that the category of the plurality of spots includes a retail store.
• and a tourist facility.
o See at least:
“The first point of interest 214 can represent an entity such as a restaurant, business, School, Scenic viewpoint, object, coordinate, or any combination thereof.” (Li, 0122)
o See also:
“The first point of interest 214 can include associated information including a name, an operating schedule, a type, a facility, a resource, or any combination thereof.” (Li, 0122)
Rationale:
Li expressly discloses that POIs may be classified by type and may include facilities and tourism-related POIs, such as scenic viewpoints. Li does not expressly recite the exact term “tourist facility.” However, it would have been obvious to a PHOSITA to include tourist facilities as a POI category in the combined Botea-Li POI recommendation system because tourist facilities are common destination categories in navigation and tourism-oriented POI systems. Including tourist facilities would have predictably improved the system’s ability to extract, filter, and notify the user of travel-relevant destinations, especially where the parent Claim 12 system already supports POI categories, opening hours, visit duration, and available-time-based recommendations.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to further configure the Claim 12 information processing device established by Botea, Akin, Onishi, Bailey, Li, and Panagiotakis such that the category of the plurality of spots includes a restaurant, a retail store, and a tourist facility. Botea provides the primary safe-mobility-area information processing device and POI framework. Akin, Onishi, Bailey, and Panagiotakis remain part of the Claim 12 parent combination because they supply mobile-terminal communication and transport-mode detection, train/stop and walking-route computation, speed-dependent virtual-area radius/filtering, and category/stay-time constraints. Li complements that Claim 12 framework by expressly disclosing POI types and facilities, including restaurants, businesses/convenience stores, and tourism-related POIs, and renders tourist facilities obvious as a predictable POI category. Incorporating Li’s known POI categories and obvious tourism-related POI classifications into the Botea-based safe-mobility POI recommendation system would have been a predictable use of known POI classification data to improve user-relevant spot extraction, filtering, and notification for common travel and tourism destinations.
Regarding Claim 15,
The combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis establishes the information processing device of Claim 12, which is the basis for Claim 15.
Disclosure by Botea
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• wherein the notification time frame
• includes a commuting time period of the user
• from Monday to Friday.
Disclosure by Akin
Akin discloses or renders obvious:
• wherein the notification time frame
o See at least:
“For example, the icon display module 230 may cause an icon to be displayed in a first configuration during one time of day (e.g., during the day), and cause the icon to be displayed in a second configuration during another time of day (e.g., during the night).” (Akin, 0047)
Rationale:
Akin expressly discloses mobile map output that varies based on time-of-day context. Akin 0047 addresses display configuration rather than notification gating. However, in the combined Claim 12 system, Botea provides current-time and user-preference-based POI output logic, and Li provides stored notification/output logic. It would have been obvious to a PHOSITA to implement a notification time frame as a stored temporal user-preference gate in that combined mobile POI notification system because notification relevance depends on when the user is traveling and when the user is receptive to receiving POI output. Thus, Akin’s time-of-day mobile-output context, combined with Botea’s current-time/user-preference framework and Li’s notification/output framework, renders obvious the claimed notification time frame.
• includes a commuting time period of the user
o See at least:
“The travel mode module 220 may determine a pedestrian mode of travel (e.g., walking, running, or other), a biking mode of travel, a driving mode of travel, a public transportation mode of travel (e.g., Subway, bus, train, or other)...” (Akin, 0023)
o See also:
“the travel mode module 220 may identify, based on GPS information, the mobile device 110 is traveling at a certain rate of speed, and/or along a certain route, and determine the mode of travel based on the identified rate of speed and/or route of travel.” (Akin, 0025)
o See also:
“For example, the icon display module 230 may cause an icon to be displayed in a first configuration during one time of day (e.g., during the day), and cause the icon to be displayed in a second configuration during another time of day (e.g., during the night).” (Akin, 0047)
Rationale:
Akin expressly discloses determining user travel mode from mobile-device GPS, speed, and route information, including driving, public transportation, subway, bus, train, and walking modes. Akin also discloses mobile output that varies by time-of-day context. Akin does not expressly recite the exact phrase “commuting time period.” However, commuting is a recurring user travel context characterized by route, speed, transport mode, and time-of-day information—the same types of travel-context information Akin acquires and uses. Akin’s travel-mode and route/speed detection already identifies the type of travel behavior that constitutes commuting, making the step of using that identified travel behavior as a commuting notification window a predictable implementation choice. In the combined Botea-Akin system, it would have been obvious to include a commuting time period of the user within the notification time frame because doing so predictably aligns POI notifications with the user’s regular travel window and improves notification relevance.
Motivation to Combine Botea and Akin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea and Akin before them, to modify Botea’s current-time and user-preference-based POI output system to use Akin’s mobile-device route, speed, travel-mode, and time-of-day context to define a notification time frame that includes the user’s commuting time period. Botea already determines POI-related output based on current time, current user location, and user preferences, while Akin provides mobile-device travel context, including route of travel, mode of travel, speed, and time-of-day display behavior. The combination would have predictably improved notification relevance by aligning POI notifications with the user’s actual recurring travel context.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea and Akin
After combining the teachings of Botea and Akin, the following claim limitation is not explicitly disclosed:
• from Monday to Friday.
Disclosure by Li
Li discloses or renders obvious:
• from Monday to Friday.
o See at least:
“The encounter validity 758 can be calculated based on the arrival time 926 being within the operating hours 924 of the first point of interest 214 as represented by the valid arrival 752 and the current date 746 being outside the dates on the closed date list 938 as represented by the seasonal availability 754.” (Li, 0225)
o See also:
“In an example of calculating the dynamic rank 740, the navigation system 700 is searching for the keyword 724 ‘amusement park’ at 8:00 PM on Saturday evening in October... The operating hours 924 indicate that the first point of interest 214 is open from ‘11:00 AM–11:00PM on Saturday and Sunday.’” (Li, 0227)
Rationale:
Li expressly discloses current-date-based validity logic and day-specific operating-hour information, including an example in which POI availability is evaluated for Saturday evening and the POI is open on Saturday and Sunday. Li does not expressly recite the exact phrase “from Monday to Friday.” However, Li establishes that the navigation system can apply day/date-based temporal constraints when determining whether POI-related output is valid. In the combined Botea-Akin-Li system, once the notification time frame includes a commuting time period of the user, configuring that recurring commuting notification period to apply from Monday to Friday would have been a routine and predictable scheduling implementation for users with Monday-to-Friday commuting patterns. Day-of-week recurrence parameters are ordinary temporal scheduling controls for applying time-based rules only on selected days. A PHOSITA would have had a finite and predictable set of scheduling options—daily, weekdays, weekends, or selected days—and would have found a Monday-through-Friday commuting window obvious for a user whose commute occurs during the ordinary workweek. This would predictably reduce irrelevant commuting-related POI notifications on non-commuting days while preserving the Claim 12 POI-notification functionality.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to further configure the Claim 12 information processing device established by Botea, Akin, Onishi, Bailey, Li, and Panagiotakis such that the notification time frame includes a commuting time period of the user from Monday to Friday. Botea provides the safe-mobility-area information processing device and current-time/user-preference framework for determining when POI-related output is appropriate. Akin provides the mobile terminal, mobile travel-context detection, route/speed/mode information, and time-of-day context relevant to identifying a commuting period. Li provides stored notification/output logic and day/date-based temporal validity logic, including current-date and day-specific operating-hour evaluation. Onishi, Bailey, and Panagiotakis remain part of the parent Claim 12 combination because they supply train/stop and walking-route computation, speed-dependent virtual-area radius/filtering, and POI category/stay-time constraints required by Claim 12. Combining these teachings would have predictably allowed the user to configure the notification time frame to match the user’s actual commuting schedule; for users with Monday-to-Friday commuting patterns, such configuration predictably limits commuting-related POI notifications to the workweek and avoids unnecessary notifications on non-commuting days while preserving the full Claim 12 functionality supplied by the entire prior-art combination.
Regarding Claim 16,
The combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis establishes the information processing device of Claim 12, which is the basis for Claim 16.
Disclosure by Botea
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• wherein the memory further stores data
• indicating dates and times
• at which the user stopped by the spots,
• and the first processor is further configured to determine
• the no-notification time frame
• via a machine learning
• using the stored data.
Disclosure by Li in view of Akin
Li, in view of Akin, discloses or renders obvious:
• wherein the memory further stores data
o See at least:
“The activity item 822 represents the name of the activity, the activity description, the number of time the activity has occurred at the first point of interest 214, how frequently the activity occurs, or any combination thereof.” (Li, 0187)
o See also:
“Once the static rank 730 has been calculated, the static rank 730 can be updated by storing the static rank 730 in a memory including the storage unit 504 of FIG. 5, the first storage unit 614 of FIG. 6, the second storage unit 646 of FIG. 6, distributed between the first storage unit 614 and the second storage unit 646, a local storage, a remote storage, a database, a cache memory, or any combination thereof.” (Li, 0194)
Rationale:
Li expressly discloses POI-related activity data, including the number of times an activity has occurred at a point of interest and how frequently the activity occurs. This directly supports storing repeated POI-interaction data. Li also expressly confirms that POI-related calculated data may be stored in memory, storage units, local storage, remote storage, a database, or cache memory. Although Li 0187’s activity-count data is associated with a POI rather than exclusively with a specific user, in the combined Botea-Akin-Li system — which is already configured to identify the user’s mobile-device location relative to POI locations — a PHOSITA would have found it obvious to record user-specific stop instances rather than only aggregate POI activity counts, because user-specific history enables personalized notification control that aggregate counts cannot. Therefore, Li’s POI activity-count/frequency data, combined with Akin’s user-specific mobile-location data, renders obvious that the memory further stores data.
• indicating dates and times
o See at least:
“The activity status 732 can also be calculated by matching the activity item 822 with the first point of interest 214, the current date 746, and an activity time threshold 826 to limit the matching to those activities occurring within the activity time threshold 826.” (Li, 0188)
o See also:
“The encounter validity 758 can be calculated based on the arrival time 926 being within the operating hours 924 of the first point of interest 214 as represented by the valid arrival 752 and the current date 746 being outside the dates on the closed date list 938 as represented by the seasonal availability 754.” (Li, 0225)
Rationale:
Li expressly discloses date-aware and time-aware POI processing, including matching POI activity items using current date and an activity time threshold, and calculating encounter validity using arrival time, operating hours, current date, and closed-date information. Li 0187 already tracks how many times and how frequently activities occur at POIs; date- and time-indexing of those occurrence records is the predictable next step for converting frequency data into temporally specific pattern data. Although Li’s cited temporal fields are directed to POI ranking and validity computations rather than expressly to historical stop records, a PHOSITA would have found it obvious to make stored user-stop-history data indicate dates and times because temporal indexing makes the historical data useful for learning recurring behavior, personalization, and notification timing.
• at which the user stopped by the spots,
o See at least:
“the travel mode module 220 may identify, based on GPS information, the mobile device 110 is traveling at a certain rate of speed, and/or along a certain route, and determine the mode of travel based on the identified rate of speed and/or route of travel.” (Akin, 0025)
o See also:
“the movement module 210 may access information from the GPS component 112 of the mobile device 110 and/or the GIS 135, such as information identifying a geographic route traveled or currently being traveled by the mobile device 110, information identifying a speed traveled or currently being traveled by the mobile device 110, information identifying a geographic location of the mobile device 110, and so on.” (Akin, 0038)
Rationale:
Akin expressly discloses GPS-based route, speed, and geographic-location information for the mobile device. Akin does not expressly recite a stored “stop” event. However, in the combined system, Botea and Li provide POI/spot locations, while Akin provides the mobile-device location, route, and speed data. A PHOSITA would have recognized that a user “stopped by” a spot when the mobile-device location corresponds to the POI/spot location and the speed/movement data indicates arrival, near-zero speed, pause, or dwell at that location. This is the ordinary operational meaning of detecting a stop event in a mobile navigation system using GPS location and speed data. A PHOSITA would also have had a reasonable expectation of success in implementing stop-event detection from Akin’s GPS location and speed data because the technical components required — location comparison and speed thresholding — were standard functions of mobile GPS systems already present in the combined Botea-Akin system. Thus, Li’s POI activity/frequency framework combined with Akin’s mobile-device route/speed/location data renders obvious storing data indicating dates and times at which the user stopped by the spots.
Motivation to Combine Botea, Akin, and Li
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, and Li before them, to store, in memory, data indicating dates and times at which the user stopped by POI spots. Botea provides the safe-mobility-area POI framework and the information processing device. Li’s POI activity-count/frequency data establishes a need for temporal indexing of user interaction records to convert frequency data into learnable temporal patterns. Akin’s GPS route/speed/location monitoring provides the detection mechanism for identifying when those interactions occur. A PHOSITA would have combined them because Akin’s mechanism for generating stop-event data is a predictable complement to Li’s framework for storing and using POI interaction history. A PHOSITA would have had a reasonable expectation of success because the combined system already includes the required inputs: POI locations, mobile-device location, route, and speed. Combining these teachings would have predictably produced a date- and time-indexed historical record of when the user stopped by spots, thereby improving personalization, later POI ranking, and time-based notification control.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea, Akin, and Li
After combining the teachings of Botea, Akin, and Li, the following claim limitations are not explicitly disclosed:
• and the first processor is further configured to determine
• the no-notification time frame
• via a machine learning
• using the stored data.
Disclosure by Panagiotakis in view of Botea, Akin, and Li
Panagiotakis, in view of Botea, Akin, and Li, discloses or renders obvious:
• and the first processor is further configured to determine
o See at least:
“Recommender Systems predict the preferences of users for specific items, based on an analysis of previous user preferences.” (Panagiotakis, p. 1)
o See also:
“smartphones, demographics, user preferences, and space-time information and ratings of itineraries for POIs visited by tourists, are easily collected providing rich datasets that can be used to infer user interests.” (Panagiotakis, p. 2)
Rationale:
Panagiotakis discloses recommender-system prediction of user preferences based on prior user preferences and further discloses that smartphone, user-preference, space-time, rating, and POI-visit itinerary data can be collected and used to infer user interests. In the combined Claim 12 information processing device, the first processor would have been further configured to determine preference-related outputs because Botea provides the processor-based device, while Li and Akin provide POI and mobile-location data used for personalization. This limitation is satisfied because the processor is further configured to determine the user-specific temporal preference later identified as the no-notification time frame.
• the no-notification time frame
o See at least:
“smartphones, demographics, user preferences, and space-time information and ratings of itineraries for POIs visited by tourists, are easily collected providing rich datasets that can be used to infer user interests.” (Panagiotakis, p. 2)
o See also:
“The encounter validity 758 can be calculated based on the arrival time 926 being within the operating hours 924 of the first point of interest 214... and the current date 746 being outside the dates on the closed date list 938...” (Li, 0225)
Rationale:
Panagiotakis discloses inferring user interests from space-time information and POI-visit itinerary data, while Li discloses temporal POI-output/ranking constraints using arrival time, operating hours, current date, and closed-date information. The no-notification time frame was already established in Claim 12 through the parent combination; Claim 16 further limits how that time frame is determined. In the combined system, it would have been obvious to determine the no-notification time frame from historical stop data because repeated dates and times at which the user stopped by POIs reveal temporal patterns of user receptiveness or non-receptiveness to POI notifications. Li’s encounter-validity logic confirms that the system already applies temporal constraints to POI output/ranking, making it a predictable extension to express learned temporal non-receptiveness as a no-notification time frame.
• via a machine learning
o See at least:
“Recommender Systems predict the preferences of users for specific items, based on an analysis of previous user preferences.” (Panagiotakis, p. 1)
o See also:
“The method of [24], the Spatio-Temporal Gated Network has been proposed to model personalized sequential data and to make predictions.” (Panagiotakis, p. 2)
Rationale:
Panagiotakis should not be read as expressly teaching that its own deterministic EM-based itinerary method is the claimed machine learning. Rather, Panagiotakis expressly identifies, in its technical background/literature discussion, that spatio-temporal gated networks have been proposed for personalized sequential POI prediction, and further explains that recommender systems predict user preferences based on previous user preferences. These disclosures establish that machine-learning approaches for sequential POI preference prediction were known in the art. A PHOSITA, having Panagiotakis’s identification of such known machine-learning techniques before them, would have found it obvious to apply a machine-learning model to the stored POI-stop history data of the combined Botea-Akin-Li system to determine the user’s temporal notification preference, including the no-notification time frame. A PHOSITA would have had a reasonable expectation of success because the claimed machine learning is not limited to a specific algorithm, and the combined system already supplies the type of historical space-time POI data used by recommender systems.
• using the stored data.
o See at least:
“smartphones, demographics, user preferences, and space-time information and ratings of itineraries for POIs visited by tourists, are easily collected providing rich datasets that can be used to infer user interests.” (Panagiotakis, p. 2)
o See also:
“Recommender Systems predict the preferences of users for specific items, based on an analysis of previous user preferences.” (Panagiotakis, p. 1)
Rationale:
Panagiotakis discloses the use of collected smartphone, space-time, user-preference, rating, and POI-visit itinerary data to infer user interests. Panagiotakis’s enumerated data types — space-time information and POI-visit itinerary data — directly correspond to the date- and time-indexed stop records stored by the combined Botea-Akin-Li system, confirming that the data produced by the combination matches the type Panagiotakis identifies as input to user-preference recommender systems. Machine-learning recommender systems inherently require input data from which preferences are learned; accordingly, applying the known machine-learning prediction techniques identified by Panagiotakis to the combined system would have used the stored historical stop data as input to the learning process.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to further configure the Claim 12 information processing device established by Botea, Akin, Onishi, Bailey, Li, and Panagiotakis such that the memory further stores data indicating dates and times at which the user stopped by the spots, and the first processor is further configured to determine the no-notification time frame via a machine learning using the stored data. Botea provides the safe-mobility-area information processing device, user-preference framework, and POI framework. Akin provides mobile-device route, speed, movement, and location data from which user stops at POI locations can be detected. Li provides POI-related activity-count/frequency data, storage, and date/time-aware POI ranking and encounter-validity logic. Panagiotakis provides recommender-system teachings using previous user preferences, smartphone data, space-time information, and POI-visit itinerary data to infer user interests, and identifies known spatio-temporal neural-network prediction approaches for personalized sequential POI prediction. Onishi and Bailey remain part of the parent Claim 12 combination because they supply train/stop and walking-route computation and speed-dependent virtual-area radius/filtering required by Claim 12. The Claim 16 limitations — stored stop-history data and machine-learning-based no-notification-time-frame determination — do not require any additional disclosure from Onishi or Bailey beyond their Claim 12 contributions; those references are carried forward as part of the established Claim 12 combination. Combining these teachings would have predictably improved the Claim 12 system by learning the user’s temporal notification-suppression preferences from actual historical stop behavior, thereby reducing unwanted spot-information output and improving personalization without requiring the user to manually specify every no-notification interval.
Regarding Claim 17,
The combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis establishes the information processing device of Claim 12, which is the basis for Claim 17.
Disclosure by Botea
Botea discloses:
• A system, comprising:
o See at least:
“In another embodiment, a computer-implemented system for presenting to a user a safe mobility area is provided, the system including a display, the system comprising: a processor; and a memory storing computer readable instructions...” (Botea, col. 4, ll. 47–55)
Rationale:
Botea expressly discloses a computer-implemented system and expressly uses the open-ended transitional language “comprising” to identify system components including a processor and memory. Therefore, Botea discloses A system, comprising:.
• information processing device;
o See at least:
“Referring now to FIG. 5, this figure shows a hardware configuration of computing system 500 according to an embodiment of the present invention. As seen, this hardware configuration has at least one processor or central processing unit (CPU) 511... random access memory (RAM) 514, read-only memory (ROM) 516... [and] a communications adapter 534 for connecting the system 500 to a data processing network, the Internet, an Intranet, a local area network (LAN), etc.” (Botea, col. 5, ll. 18–35)
Rationale:
Botea expressly discloses the primary processor-based information-processing-device framework. This limitation incorporates the information processing device of Claim 12. The full Claim 12 information processing device is established by the parent-claim combination of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis. Therefore, Botea provides the primary structural anchor, while the complete the information processing device according to claim 12; and is supplied by the full parent combination.
Claim Limitations Not Explicitly Disclosed by Botea
Botea does not explicitly disclose the following claim limitations:
• and the mobile terminal, wherein
• the mobile terminal includes
• a display, and
• a second processor
• configured to cause the display
• to display a message
• corresponding to the notification
• in response to the mobile terminal receiving the notification
• transmitted from the information processing device.
Disclosure by Akin
Akin discloses:
• and the mobile terminal, wherein
o See at least:
“The example network system 100 may facilitate the exchange of data between the mobile device 110 and the map icon display system 130.” (Akin, 0019)
Rationale:
Akin expressly discloses a mobile device exchanging data with a map icon display system. The mobile device corresponds to the claimed mobile terminal.
• the mobile terminal includes
o See at least:
“The mobile device 110 may include a GPS component 112, an accelerometer 114, a compass 116, a gyroscope 118, a camera 120, a microphone 122, a speaker 124, and so on.” (Akin, 0020)
Rationale:
Akin expressly discloses that the mobile device includes hardware components. The listed components are non-exclusive, as shown by “and so on.” Therefore, Akin expressly discloses that the mobile terminal includes components, and a PHOSITA would have understood such a mobile device to include standard user-interface hardware, including at minimum a display screen, needed to implement the mapping application and display functions described in Akin.
• a display, and
o See at least:
“The mobile device 110 may include a GPS component 112, an accelerometer 114, a compass 116, a gyroscope 118, a camera 120, a microphone 122, a speaker 124, and so on.” (Akin, 0020)
o See also:
“FIG. 6A depicts a user interface 600 of the mobile device 110, which presents a walking icon 615 within a map 610 displayed by a mapping application 115 supported by the mobile device 110.” (Akin, 0054)
o See also:
“FIG. 6D depicts a user interface 640 of the mobile device 110, which presents a bus icon 655, along with display elements 657, 659 associated with bus stops, within a map 650 displayed by a mapping application 115 supported by the mobile device 110.” (Akin, 0057)
2
Akin expressly discloses a mobile device with a non-exclusive list of hardware components and expressly discloses user interfaces of the mobile device that present maps, icons, and display elements through a mapping application. A user interface presenting maps and icons on a mobile device necessarily includes a display or display screen. Therefore, Akin discloses or at least renders obvious that the mobile terminal includes a display.
Motivation to Combine Botea and Akin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea and Akin before them, to implement Botea’s information-processing-device framework in a system that further includes Akin’s user mobile terminal having a user interface/display for presenting map-based information. Botea already computes and provides safe-mobility and POI information to a user, while Akin expressly discloses a mobile device that exchanges data with a map icon display system and displays map-based icons and elements through a mobile mapping application. This is a partial combination addressing the mobile-terminal/display structure; additional limitations concerning the second processor, message display, notification response, and transmission source are addressed by Li below and by the final full motivation to combine.
Claim Limitations Not Explicitly Disclosed by the Combination of Botea and Akin
After combining the teachings of Botea and Akin, the following claim limitations are not explicitly disclosed:
• a second processor
• configured to cause the display
• to display a message
• corresponding to the notification
• in response to the mobile terminal receiving the notification
• transmitted from the information processing device.
Disclosure by Li
Li discloses or renders obvious:
• a second processor
o See at least:
“The control unit 508 can execute a software 512 to provide the intelligence of the navigation system 100.” (Li, 0053)
o See also:
“The control unit 508 can be implemented in a number of different manners. For example, the control unit 508 can be a processor, an embedded processor, a microprocessor...” (Li, 0054)
Rationale:
Li expressly discloses a control unit that executes software to provide the intelligence of the navigation system, and further discloses that the control unit may be implemented as a processor, embedded processor, or microprocessor. In the combined system, Botea supplies the processor of the information processing device, and Li’s mobile-device control unit supplies a separate processor of the mobile terminal. Therefore, Li discloses or renders obvious a second processor.
• configured to cause the display
o See at least:
“The control unit 508 can operate the user interface 502 to display information generated by the navigation system 100.” (Li, 0053)
o See also:
“The display interface 202 can include a display, a projector, a video screen, a speaker, or any combination thereof.” (Li, 0052)
Rationale:
Li expressly discloses that the control unit operates the user interface to display information generated by the navigation system, and that the display interface may include a display. Thus, Li discloses a processor configured to cause the display to display information.
• to display a message
o See at least:
“The storage unit 504 can also store the relevant information, such as data representing incoming images, data representing previously presented image, sound files, messages, notifications, points of interest (POI), navigation routing entries, or any combination thereof.” (Li, 0062)
o See also:
“The control unit 508 can operate the user interface 502 to display information generated by the navigation system 100.” (Li, 0053)
Rationale:
Li expressly discloses messages as a category of information in the navigation system and further discloses that the control unit operates the user interface to display information generated by the navigation system. Therefore, Li discloses or renders obvious to display a message.
• corresponding to the notification
o See at least:
“The storage unit 504 can also store the relevant information, such as data representing incoming images, data representing previously presented image, sound files, messages, notifications, points of interest (POI), navigation routing entries, or any combination thereof.” (Li, 0062)
o See also:
“The control unit 508 can operate the user interface 502 to display information generated by the navigation system 100.” (Li, 0053)
Rationale:
Li expressly discloses both “messages” and “notifications” within the same navigation-system information framework and discloses that the control unit operates the user interface to display information generated by the navigation system. In the Claim 12 system, the notification includes spot information such as POI details and opening hours. A displayed message corresponding to the notification is the user-facing textual or graphical representation of that received notification content. Thus, Li’s disclosure of messages and notifications as displayable navigation-system information renders obvious a displayed message whose content is derived from and represents the received notification.
• in response to the mobile terminal receiving the notification
o See at least:
“The communication unit 510 can enable external communication to and from the first device 102.” (Li, 0067)
o See also:
“The communication interface 520 can receive information from the other functional units or can transmit information to the other functional units.” (Li, 0069)
o See also:
“The control unit 508 can operate the user interface 502 to display information generated by the navigation system 100.” (Li, 0053)
Rationale:
Li expressly discloses that the mobile device has a communication unit enabling external communication to and from the device, and that its control unit operates the user interface to display information generated by the navigation system. In view of Claim 12’s established transmission of the notification to the mobile terminal, it would have been obvious for the mobile terminal’s processor to cause display of the corresponding message in response to receiving that notification. The predictable purpose of transmitting a user-facing notification to a mobile terminal is to cause the terminal to present the received notification content to the user.
• transmitted from the information processing device.
o See at least:
“The example network system 100 may facilitate the exchange of data between the mobile device 110 and the map icon display system 130.” (Akin, 0019)
o See also:
“The communication unit 510 can enable external communication to and from the first device 102.” (Li, 0067)
Rationale:
Akin 0019 is cited here for the data-exchange/transmission pathway between the mobile device and the map icon display system, not merely for the mobile-terminal structure previously addressed. Li expressly discloses external communication to and from a mobile device. The parent Claim 12 combination already establishes transmitting a notification from the information processing device to the mobile terminal. Thus, in the Claim 17 system, the mobile terminal receiving and displaying the notification transmitted from the information processing device would have been an obvious implementation of the communication and display functions taught by Akin and Li.
Motivation to Combine Botea, Akin, Onishi, Bailey, Li, and Panagiotakis
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Botea, Akin, Onishi, Bailey, Li, and Panagiotakis before them, to further configure the Claim 12 information processing device and mobile-terminal arrangement such that the mobile terminal includes a display and a second processor configured to cause the display to display a message corresponding to the notification in response to the mobile terminal receiving the notification transmitted from the information processing device. Botea provides the primary information-processing-device and safe-mobility POI framework. Akin provides the mobile terminal, data exchange with a map/display system, and a mobile mapping interface that displays map-based icons and elements to the user. Li provides a mobile-device architecture having a user interface/display, a control unit implemented as a processor, a communication unit for external communication, and message/notification information displayed through the user interface. Onishi, Bailey, and Panagiotakis remain part of the parent Claim 12 combination because Onishi supplies train/stop-point route data and walking-route computation from a station/stop, Bailey supplies speed-dependent virtual-area radius computation and filtering of out-of-range items, and Panagiotakis supplies POI category and stay-time itinerary constraints required by Claim 12. The Claim 17 limitations do not require additional disclosure from Onishi, Bailey, or Panagiotakis beyond their Claim 12 parent roles. A PHOSITA would have had a reasonable expectation of success in implementing the combined system because all required components — an information processing device with a communications adapter, a wireless-capable mobile terminal, a mobile-terminal processor, a display, a user interface, and a communication unit — were standard, well-understood components routinely combined in mobile navigation and notification systems. A PHOSITA would have been motivated to transmit the notification from the server-side information processing device to the mobile terminal rather than computing it locally because Botea’s framework centralizes POI and safe-mobility computation at the information processing device, and Akin’s disclosed data exchange between the mobile device and the map icon display system confirms the standard architecture of server-to-mobile notification delivery. Combining Akin’s mobile-terminal display interface and Li’s mobile-device processor/display/communication architecture with Botea’s Claim 12 information-processing-device system would have predictably allowed the received notification to be rendered as a displayed message on the mobile terminal, thereby improving user-facing delivery of POI notification information.
Response to Arguments
Regarding the 35 U.S.C. § 112(b) Rejection
Applicant’s amendments and remarks filed in response to the rejection of claim 12 under 35 U.S.C. § 112(b) have been fully considered and are persuasive.
The prior rejection under 35 U.S.C. § 112(b) was based on the recitations “optimally arrives at the extracted spot” and “and/or” in claim 12, which rendered the scope of the claim indefinite.
In response, Applicant amended claim 12 to address the indefiniteness issues identified in the prior Office Action. As amended, claim 12 no longer includes the indefinite phrase “optimally arrives at the extracted spot” or the ambiguous “and/or” language that formed the basis of the rejection. The amended claim language now reasonably apprises one of ordinary skill in the art of the scope of the claimed invention with reasonable certainty.
Accordingly, the rejection of claim 12 under 35 U.S.C. § 112(b) is withdrawn.
Regarding the 35 U.S.C. § 101 Rejection
Applicant’s arguments filed in response to the rejection under 35 U.S.C. § 101 have been fully considered but are not persuasive. Applicant argues that amended claim 12 is patent-eligible because the claim allegedly:
(1) structurally constrains computation by extracting only spots located in the virtual area and excluding out-of-area spots from further computations;
(2) reduces computational workload, memory usage, computation time, latency, and HMI output load; and
(3) provides a device-level notification suppression control that integrates the alleged abstract idea into a practical application and supplies significantly more than the judicial exception.
The Examiner respectfully disagrees for the reasons set forth below.
I. The Claimed “Virtual Area” and “Exclusion” Limitations Do Not Integrate the Abstract Idea into a Practical Application
Applicant argues that amended claim 12 is not directed merely to data filtering because the claim “extract[s] only a spot located in the virtual area” and “exclude[s] any spot outside the virtual area from further computations,” thereby allegedly reducing computation time, memory usage, and latency.
This argument is not persuasive.
The claimed extraction and exclusion limitations are part of the abstract decision process itself. They define which spot information is considered and which spot information is not considered when determining whether a notification should be transmitted. The limitations therefore refine the informational selection criteria used in the abstract recommendation/notification process, but they do not improve the operation of the underlying computer, processor, memory, communication unit, map database, route-search engine, mobile terminal, GPS technology, or display technology.
Under the USPTO eligibility framework, Step 2A, Prong Two asks whether the claim as a whole integrates the judicial exception into a practical application by evaluating the additional elements individually and in combination. Merely using generic computer components to perform data selection, analysis, and output does not integrate an abstract idea into a practical application.
Here, claim 12 does not recite a specific improved database architecture, indexing structure, memory-management technique, processor architecture, route-search algorithm, communication protocol, or geospatial data structure. Instead, the claim recites the result of excluding out-of-area spots from further computations. A claimed result of reducing the amount of information processed, without reciting a specific technological mechanism for achieving an improvement in computer functionality, does not transform the abstract selection and notification process into a practical application.
Thus, even if the claimed exclusion of out-of-area spots may reduce the number of spot records considered, that reduction is a consequence of applying the abstract selection rule, not a technological improvement to the computer system itself.
II. Applicant’s Alleged Computational Efficiency Is Not Sufficient Because the Claim Does Not Recite a Specific Technological Improvement
Applicant further argues that the virtual-area extraction limitation provides “technological benefits” such as efficiency and latency reduction.
This argument is not persuasive because the claim does not recite how the processor, memory, route-search engine, or database is technologically improved. The claim merely recites narrowing the search domain based on a virtual area and excluding spots outside that area. That is an abstract information-filtering rule implemented using generic information-processing components.
The Federal Circuit has held that claims directed to collecting information, analyzing information, and displaying or transmitting the results are directed to an abstract idea where the claims do not recite a specific technological improvement. In Electric Power Group, the court explained that collecting data from multiple sources, analyzing it, and displaying results, even in a real-time technological environment, was abstract where the claims focused on information analysis rather than an improvement to computer technology.
The present claim is analogous. Claim 12 collects user location and speed information, analyzes map/spot/time information, selects spots, computes arrival-time conditions, and transmits or suppresses a notification. The fact that the claim excludes some spot records before performing further computations does not change the focus of the claim from information selection and notification to a technological improvement.
Accordingly, Applicant’s alleged reduction in workload or latency is not sufficient to overcome the rejection because the claim does not recite a concrete technical solution to a technical problem in computer functionality.
III. The Notification Suppression Limitations Remain Part of the Abstract Idea
Applicant also argues that amended claim 12 imposes a “device-level constraint on notification output” by suppressing notification output when the current time falls within a no-notification time frame or outside an available time frame. Applicant asserts that this reduces unnecessary notifications and HMI output load.
This argument is not persuasive.
The notification suppression limitations merely define when information is presented to the user and when information is withheld from the user. These limitations are part of the abstract idea of managing a user’s schedule, travel behavior, and notification preferences. They do not improve the operation of the mobile terminal, display, notification controller, communication unit, or HMI technology.
Suppressing a notification based on a user’s availability or no-notification time frame is an informational and behavioral rule. It controls the content and timing of the information presented to the user. The claim does not recite an improved display architecture, reduced-power display control, improved notification protocol, improved graphical user interface, improved device resource allocation, or improved HMI structure. Rather, the claim simply states that the notification is transmitted only if certain time and arrival conditions are satisfied and is otherwise suppressed.
Therefore, the notification-suppression limitation does not integrate the abstract idea into a practical application. It is instead part of the abstract recommendation and notification logic.
IV. The Alleged Reduction of HMI Output Load Does Not Establish a Technological Improvement
Applicant argues that suppressing notifications reduces “HMI output load,” including display updates and user-attention demands.
This argument is not persuasive.
Reducing the number of notifications displayed to a user is not, by itself, an improvement to display technology or HMI technology. The claim does not recite a particular display-control architecture, user-interface layout, display-refresh technique, power-saving display mechanism, notification rendering method, or HMI processing improvement. The claim merely determines whether a notification should be provided or suppressed based on user availability, no-notification time, and arrival-time conditions.
Any reduction in display updates results from the abstract rule of suppressing selected notifications, not from a technological improvement in how the display or HMI operates. Improving the relevance, timing, or usefulness of information presented to a user is not the same as improving the functioning of the device itself.
Accordingly, the alleged HMI-load reduction does not amount to integration into a practical application and does not supply an inventive concept.
V. The Claimed Combination Does Not Amount to Significantly More Than the Abstract Idea
Applicant argues that the claimed combination of virtual-area extraction, transport-mode determination, arrival-time computation, and notification suppression supplies significantly more than the alleged abstract idea.
This argument is not persuasive.
The claim as a whole remains directed to collecting user location, travel, time, and point-of-interest information; determining whether a point of interest should be presented to the user; and selectively providing or suppressing a notification based on that determination. The claim’s components — memory, clock, processor, communication unit, and mobile terminal — perform their ordinary functions of storing information, providing time information, processing data, communicating data, and receiving/displaying notifications.
Under Step 2B, additional elements must amount to significantly more than the judicial exception. The USPTO’s Berkheimer memorandum explains that findings that additional elements are well-understood, routine, and conventional must be supported by appropriate factual support, including judicial decisions, publications, specification admissions, or properly taken official notice.
Here, the additional elements are generic computer and mobile-device components performing generic functions. The claim does not recite any unconventional hardware arrangement, specialized processor, improved memory structure, improved route-search engine, improved geospatial database, improved communication protocol, or improved mobile-terminal display. As an ordered combination, the claim merely performs the abstract process using generic computer components: storing data, receiving location/speed information, determining transport mode, defining a virtual area, selecting spots, computing arrival times, comparing timing conditions, and transmitting or suppressing a notification.
The Federal Circuit has repeatedly held that such generic computer implementation of information collection, analysis, and output does not supply an inventive concept. See Alice Corp. v. CLS Bank Int’l, 573 U.S. 208 (2014); Electric Power Group, 830 F.3d 1350; FairWarning IP, LLC v. Iatric Systems, Inc., 839 F.3d 1089; and Affinity Labs of Texas, LLC v. DIRECTV, LLC, 838 F.3d 1253.
Thus, the ordered combination does not transform the abstract idea into patent-eligible subject matter.
VI. The Claim Is Distinguishable from Enfish, McRO, and Core Wireless
To the extent Applicant contends that the amended claim improves location-based notification technology, that argument is not persuasive.
The claim does not improve the way a computer stores or retrieves data, as in Enfish. The claim does not recite a self-referential table, improved database structure, or any other specific improvement to computer memory or database operation.
The claim also does not improve a specific technological process through particular claimed rules, as in McRO. The claimed virtual-area, arrival-time, and notification-suppression rules govern what information is selected and when it is provided to the user. They do not improve an underlying technological process.
Nor is the claim analogous to Core Wireless, where the claims recited a specific improved user interface. Claim 12 does not recite a specific improved interface, display layout, or mobile-terminal interaction architecture. Claim 17 merely recites displaying a message corresponding to the notification.
Accordingly, the present claims are unlike those in Enfish, McRO, and Core Wireless because the alleged improvement is to the relevance and timing of information provided to the user, not to the operation of the computer or mobile device itself.
VII. Applicant Has Not Shown That the Claimed Subject Matter Improves Machine, Computer, or Mobile-Device Technology
Applicant’s arguments focus on reduced computation, reduced memory usage, reduced latency, reduced notifications, and reduced HMI output load. However, claim 12 does not recite the technological details necessary to establish such improvements as improvements to computer functionality.
The claim does not recite:
a particular improved geospatial database structure;
a particular improved route-search algorithm;
a particular improved memory-management technique;
a particular improved processor operation;
a particular improved communication protocol;
a particular improved mobile-device notification architecture;
a particular improved display or HMI structure; or
a particular improved machine-learning model or training technique.
Instead, the claim recites generic computing components used to perform abstract information selection, timing analysis, and notification suppression. The 2024 USPTO subject matter eligibility guidance confirms that, at Step 2A, Prong Two, the analysis turns on whether the claim as a whole integrates the judicial exception into a practical application, not merely whether the claim produces useful information or a desirable result.
Therefore, the alleged benefits do not overcome the § 101 rejection.
VIII. Conclusion
For the reasons stated above, Applicant’s arguments have been considered but are not persuasive.
The amended claim still recites the abstract idea of collecting user location, travel, time, and point-of-interest information; determining whether a point of interest should be presented to the user; and selectively providing or suppressing a notification based on that determination.
The virtual-area extraction limitation merely narrows the information considered in the abstract recommendation process. The arrival-time computation limitations merely perform mathematical and logical determinations used in the notification decision. The available-time and no-notification-time limitations merely impose user-schedule and preference rules. The notification-suppression limitation merely controls whether information is output to the user.
Taken individually and as an ordered combination, these limitations do not improve computer technology, route-search technology, map-database technology, GPS/location technology, communication technology, display technology, HMI technology, or mobile-device technology. Rather, they implement the abstract notification-selection process using generic computer and mobile-device components.
Accordingly, the rejection of claims 12–17 under 35 U.S.C. § 101 is maintained.
Response to Applicant’s Arguments Regarding 103 Rejection
Applicant’s arguments have been fully considered but are not persuasive.
Applicant argues that amended claim 12 is patentable because Botea does not disclose that “a size of the virtual area differs for each category of the plurality of spots,” and because Akin, Onishi, Bailey, Li, and Panagiotakis allegedly do not remedy that deficiency. Examiner respectfully disagrees.
As an initial matter, Applicant’s argument improperly attacks the references individually, whereas the rejection is based on the combined teachings of Botea, Akin, Onishi, Bailey, Li, and Panagiotakis. One cannot show nonobviousness by attacking references individually where the rejection is based on a combination of references. See In re Keller, 642 F.2d 413, 425 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir. 1986); MPEP § 2145.
The Examiner is not relying on Botea alone as expressly teaching that “a size of the virtual area differs for each category of the plurality of spots.” Rather, Botea is relied upon for the underlying safe-mobility/virtual-area framework. Botea discloses mechanisms for computing and displaying a safe mobility area, where the safe mobility area is “an area inside which a user can act without jeopardizing a final goal specified by the user” (Botea, col. 6, ll. 22–28). Botea further discloses that the safe mobility area may be dynamically computed and may shrink as time passes (Botea, col. 6, ll. 36–40). Thus, Botea discloses a dynamically computed virtual/safe area having a variable size or extent.
Bailey is relied upon for variable map-range sizing and geographic filtering. Bailey discloses that a data conversion module “converts an input vehicle speed signal to a distance range value” (Bailey, col. 4, ll. 10–13). Bailey further discloses that, when the vehicle speed input signal is between lower and upper speed limits, the “Map Range (distance range value) is set equal to the vehicle speed multiplied by the Range Gain Factor” (Bailey, col. 6, ll. 59–64). Bailey also discloses separating items within the determined map range from items outside the map range (Bailey, col. 7, ll. 10–16). Thus, Bailey teaches a variable range or area-size mechanism used to determine which geographic items are included or excluded.
Panagiotakis is relied upon for the POI-category constraint framework. Panagiotakis discloses that POIs are divided into categories and that the itinerary recommendation problem accounts for POI category constraints and spatial constraints (Panagiotakis, p. 1). Panagiotakis further discloses minimum/maximum limits on the number of POIs belonging to each category (Panagiotakis, p. 1). Thus, Panagiotakis teaches that POI selection may be constrained by category and spatial considerations.
In view of these combined teachings, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to configure Botea’s dynamic virtual/safe mobility area using Bailey’s variable map-range/filtering technique and Panagiotakis’s category-based POI constraints such that “a size of the virtual area differs for each category of the plurality of spots.” Different categories of POIs predictably have different densities, user priorities, and category-count requirements. For example, a sparse or required category would predictably require a larger virtual/search area to locate enough candidate spots, whereas a dense or already-satisfied category would predictably require only a smaller area to reduce unnecessary computations and avoid irrelevant or excessive notifications. This is a predictable use of known elements according to their established functions: Botea supplies the dynamic virtual/safe area (Botea, col. 6, ll. 22–40), Bailey supplies variable map-range sizing and filtering (Bailey, col. 4, ll. 10–13; col. 6, ll. 59–64; col. 7, ll. 10–16), and Panagiotakis supplies category-based POI constraints and spatial constraints (Panagiotakis, p. 1).
Applicant’s assertion that none of the cited references expressly discloses varying a search-area size depending on spot category is not sufficient to overcome the rejection. The rejection does not require Botea alone, Bailey alone, or Panagiotakis alone to disclose the full amended limitation. Under § 103, the relevant inquiry is whether the combined teachings of the references would have rendered the claimed subject matter obvious to a person of ordinary skill in the art. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 416–421 (2007); MPEP § 2143.
Here, the combination provides a rational, predictable, and technically compatible modification. Botea’s safe mobility area is already dynamically computed for POI visitation (Botea, col. 6, ll. 22–40). Bailey teaches varying the map range and filtering items based on the determined range (Bailey, col. 6, ll. 59–64; col. 7, ll. 10–16). Panagiotakis teaches POI categories, category constraints, spatial constraints, and minimum/maximum category limits (Panagiotakis, p. 1). Applying Bailey’s variable range to Botea’s safe mobility area in view of Panagiotakis’s category constraints would have predictably improved POI retrieval by adapting the virtual-area size to the density and requirements of each category, thereby improving computational efficiency and recommendation relevance.
Applicant has not identified any teaching away, technical incompatibility, unexpected result, or criticality associated with using different virtual-area sizes for different POI categories. Nor has Applicant shown that varying the area size by category would have been beyond the ordinary skill in the art. Rather, the claimed feature represents the predictable application of known category-constrained POI selection to a known dynamic map-area/range filtering framework.
Accordingly, Applicant’s arguments do not overcome the rejection of claim 12 under 35 U.S.C. § 103. The rejection of claim 12 is maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 OLUWABUSAYO ADEBANJO AWORUNSE whose telephone number is (571)272-4311. The examiner can normally be reached M - F (8:30AM - 5PM).
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, Jelani Smith can be reached at (571) 270-3969. 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.
/OLUWABUSAYO ADEBANJO AWORUNSE/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662
Prosecution Insights