DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
Newly submitted amended claims 4,7,8,9,10,11,12,13,14,15,18,19,20 are directed to an invention that is independent or distinct from the invention originally claimed for the following reasons: The original presented claims were directed to geographic-area and POI/geofenced-based rule features. Newly submitted amended claims are directed to different rule-triggering features, including non-location event conditions such as in-app activity, onboard sensors that indicated battery life and connectivity strength, temporal conditions, tampering, and action frequency limits.
Since applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits. Accordingly, claims 4,7,8,9,10,11,12,13,14,15,18,19,20 withdrawn from consideration as being directed to a non-elected invention. See 37 CFR 1.142(b) and MPEP § 821.03.
To preserve a right to petition, the reply to this action must distinctly and specifically point out supposed errors in the restriction requirement. Otherwise, the election shall be treated as a final election without traverse. Traversal must be timely. Failure to timely traverse the requirement will result in the loss of right to petition under 37 CFR 1.144. If claims are subsequently added, applicant must indicate which of the subsequently added claims are readable upon the elected invention.
Should applicant traverse on the ground that the inventions are not patentably distinct, applicant should submit evidence or identify such evidence now of record showing the inventions to be obvious variants or clearly admit on the record that this is the case. In either instance, if the examiner finds one of the inventions unpatentable over the prior art, the evidence or admission may be used in a rejection under 35 U.S.C. 103 or pre-AIA 35 U.S.C. 103(a) of the other invention.
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 1-2,5,6,14,15,16,17 are rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard)
Regarding claim 1, Jao discloses a mobile telephone including a location infrastructure application configured to provide location information to a server, and receive responses from the server, the mobile telephone comprising:
a location determining module configured to generate location information related to a position of the mobile telephone (Par. 34: Lines 1-15; The UE includes a GPS signal sensor);
the mobile telephone sending the location information to a server (Par. 38: Lines 1-3; The if-this-then-that (IFTTT) based app is installed on a server; Par. 42: Lines 7-12; There are GPS-based triggering events; Par. 46; The IFTTT is GPS based. When the phone enters a specific radius (location), corresponding actions are performed according to the triggering events);
receiving, at a server for the location infrastructure application (Par. 28: Lines 1-16; The server hosting the IFTTT-based app establishing platform corresponds to “the server for the location infrastructure application”, since it manages and processes rule creation for location-based triggers. The act of the user filling and submitting the from through the interface maps to “receiving, at the server” because the server receives the user’s rule selection) and from a client via a rules builder interface (Par. 42: Lines 1-7; The user is able to select a triggering event via the IFTTT rule addition page; This shows the client interacts with the rules builder interface – the on-screen “IF” menu – to define a GPS-based triggered event, demonstrating that the trigger is received from the client via the rules builder interface), a first user context selection to serve as a trigger for a first rule (Par. 42: Lines 1-7; The user is able to select a triggering event via the IFTTT rule addition page), the first user context specifying a first user context that includes detection of a first event occurring in or near a first pre-defined geographic area (Par. 37: Lines 1-5; For example, a user can define to enable the phone to beep when the phone approaches a predetermined location; Choosing an action IF the phone approaches a predetermined location is the user context);
receiving, at the server (Par. 28: Lines 1-16; The act of the user filling and submitting the from through the interface maps to “receiving, at the server” because the server receives the user’s rule selection) and from the client via the rules builder interface (Par. 42: Lines 1-7; The user is able to select a triggering event via the IFTTT rule addition page; This shows the client interacts with the rules builder interface – the on-screen “IF” menu – to define a GPS-based triggered event, demonstrating that the trigger is received from the client via the rules builder interface), a response selection for the first rule, the response selection including at least a first action to be implemented by the location infrastructure application upon detection that all the conditions specified by the first user context selection are satisfied (Par. 37: Lines 1-5; For example, a user can define to enable the phone to beep when the phone approaches a predetermined location; Choosing the action THAT happens IF the conditions is the response; Par. 41: Lines 25-27 and Fig. 3a and Fig. 3b; The user is able to choose the action that happens (THAT) if conditions are met (IF). This defines the if-this-then-that architecture.
Jao does not disclose the mobile telephone receiving from the server instructions to perform at least one action based on the location infrastructure sent to the server.
Kussela, however, discloses the mobile telephone receiving from the server instructions to perform at least one action based on the location infrastructure sent to the server (Par. 36: Lines 3-12; The server (system 100) determines when a location-based condition is satisfied (e.g., a user device entering or leaving a predefined area) and in response, sends a message to the user device to activate or deactivate a point-of-interest record).
Therefore, it would have been obvious to a person having ordinary skill in the art to modify Jao’s cloud-hosted IFTTT rule platform so then, when a location-based rule is satisfied, the server sends instructions to the handset as taught by Kussela. This would have the benefit of centralized enforcement, consistent behavior across devices, and reduced on-device processing.
Jao in view of Kussela do not disclose receiving, at the server and from a mobile telephone, first location data for the mobile telephone over a first period of time;
verifying, at the server and based on the first location data, the first event occurred in or near the first pre-defined geographic area;
and causing, by the server and in response to the verification, the first action to be performed.
Lidin, however, discloses receiving, at the server and from a mobile telephone, first location data for the mobile telephone over a first period of time (Par. 12: Lines 6-9l The server obtains the location of the primary device; Par. 39: Lines 9-15; To ensure the location obtained is the latest location, there are timers associated; This corresponds to obtaining location over a predefined period of time);
verifying, at the server and based on the first location data, the first event occurred in or near the first pre-defined geographic area (Par. 43: Lines 14-20; The server determines mutual distances between devices and if any of the devices are within a predetermined proximity range; Par. 14: Lines 1-4; The server determines whether a device is located withing a predetermined proximity range; The server is determining a location-based event (entering or being near a predefined area));
and causing, by the server and in response to the verification, the first action to be performed (Par. 12: Lines 6-14; If a proximity range is met, a service-related operation (first action) is performed).
Therefore, it would have been obvious to a person having ordinary skill in the art to incorporate Lidin’s server-side receipt of handset location over time, server verification of a geo-fence event, and server-caused action into the Jao in view of Kussela system. This would have the benefit of more accurate trigger detection (fewer false events), network-aware policy application, and efficient, scalable rule execution.
Jao in view of Kussela in further view of Lidin discloses a rules builder interface where a user context selection triggers a rule upon detection that a mobile phone is determined to be within a predefined geographic area.
Jao in view of Kussela in view of Lidin does not disclose a user context selection of a points-of-interest (POI) database, wherein: the POI database identifies place categories including commercial store chains, malls, groceries, gas stations, and schools, and each place category in the POI database includes location information about all POIs classified within that place category.
Guichard, however, discloses a database storing place-related entries/categories and associated information, wherein the entries/categories include commercial store chains, malls, groceries, gas stations, and schools and further include GPS coordinates and address information associated with such entries (Par. 64: Lines 1-10; Place related information is stored and maintained in a database; Par. 63; Place-related entries/categories include grocery stores, gas stations, retail stores, malls, school, and GPS coordinates and address information associated with such entries).
Therefore, it would have been obvious to a person having ordinary skill in the art to modify the location-based rule platform of Jao in view of Kussela and Lidin to utilize a POI database organized according to place categories, such as commercial stores, malls, groceries, gas stations, and schools, with associated location information as taught by Guichard, so that the user context selection for the rule trigger may be defined by a selected place category rather than only a manually specified geographic location. This would have had the benefit of improving the flexibility and scalability of the location-based rule system by allowing a single rule to apply across multiple POIs of the same type, while also improving organization and retrieval of location-trigger definitions through categorized POI information.
Regarding claim 2 as applied to claim 1, Jao discloses a location infrastructure application running on a mobile telephone (Par. 35: Lines 6-8; The if-this-then-that application is installed on a mobile telephone).
Jao does not disclose wherein a receipt of a signal from the server causes the first action to be performed via the location infrastructure application running on a mobile telephone. Kussela however, discloses a receipt of a signal causing a first action to be performed (Par. 36: Lines 3-12; The server (system 100) determines when a location-based condition is satisfied (e.g., a user device entering or leaving a predefined area) and in response, sends a message (signal) to the user device to activate or deactivate a point-of-interest record (first action)).
Therefore, it would have been obvious to a person having ordinary skill in the art to incorporate Kussela’s server-initiated message (signal) trigger into Jao’s handset-resident location application so that, upon receipt of the server’s signal, the on-device application performs the elected action. This would achieve centralized rule evaluation and policy enforcement with reliable, low-latency activation on the handset.
Regarding claim 5 as applied to claim 1, Jao discloses wherein the rules builder interface includes a graphical user interface (GUI) menu offering selectable options, each selectable option designating one of a set of pre-defined user context types from which the user context selection was made (Fig 3a and 3b; The GUI shows triggering events (IF); Par. 42: Lines 3-12; The IFTTT rule addition page includes user input triggering events and rules).
Regarding claim 6 as applied to claim 5, Jao discloses wherein the user context selection can include one or more additional predefined user context types that include one or more of: a geofence context type, a beacon context type, a trips context type, a regions context type, and a fraud context type (Fig 3a and 3b; The IF user context menu includes; Par. 42: Lines 7-11; The IF events can include a GPS triggering event; Geo-fence context type).
The remaining limitations were given no patentable weight due to the optional language “or”.
Regarding claim 14, the rejection of claim 1 addresses the limitations of claim 14. Therefore, the limitations of claim 14 have been addressed.
Regarding claim 15 as applied to claim 14, Jao discloses presenting, via the rules builder interface and when the client is making the second selection, a list of selectable options, each selectable option corresponding to one action type from a set of action types that include notifications, navigation, tracking, and user experience configurations for the mobile application (Fig. 3a and 3b and Par. 41: Lines 1-11; The user selects the action (THAT) from the rule addition page and may configure an action such as beeping/alerting (notifications) when a location condition is met).
Regarding claim 16, the rejection of claim 1 addresses the limitations of claim 16. Therefore, the limitations of claim 16 have been addressed. A processor and machine-readable media are necessary components of a system that is able to perform the recited functions.
Regarding claim 17 as applied to claim 16, the rejection of claim 2 addresses the limitations presented in claim 17. Therefore, the limitations of claim 17 have been addressed.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Vaynblat et al. (US 9648581, hereinafter Vaynblat).
Regarding claim 3 in view of claim 2, Jao in view of Kussela disclose a signal received by a location infrastructure running on a mobile telephone (as detailed in the rejection of claim 2).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose the signal being received by a software development kit (SDK) associated with the location infrastructure app.
Vaynblat, however, discloses a geofence SDK on a device that transmits a backend sending a signal to an SDK installed on a device (Col. 12: Lines 8-13; The systems backend sends selected geofences to the SDK).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Vaynblat’s SDK-based communication into Jao (as modified by Kussela and Lidin and Guichard) so that the server’s signal is received by an SDK on the device associated with the location app. Vaynblat teaches a backend sending selected geofences to an SDK installed on the device, which then updates local data. Using such an SDK interface would have been a predictable and routine way to handle server-to-device messages, improving reliability and simplifying integration between the app and backend.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Vanscoyk et al. (US 20170135113, hereinafter Vanscoyk).
Regarding claim 4 as applied to claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses a first action to be performed via a location infrastructure application running on a mobile telephone (as detailed in the rejection of claim 2).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the first action to be preformed includes modifying an account setting for a first user.
Vanscoyk, however, discloses rules defining actions that can be takes in response to detecting conditions such as modifying a user account (Par. 36: Lines 1-16; If the user device enters a location, the server can detect a rule triggered by entry into the location and in response, actions such as updating a user profile can be taken).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Vanscoyk’s account/profile-update action into the combined Jao–Kussela–Lidin-Guichard system so that, when a rule is triggered by the verified location event, the server (or handset app per received instruction) performs a routine account-setting modification for the user. Doing so is a predictable use of known rule-engine actions to improve personalization and policy enforcement, merely substituting one well-understood action (updating a user profile/account setting) for the other disclosed actions in Jao/Kussela without changing the system’s principle of operation.
Claims 7,8,9,11,18,19,20 are rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Jones (US 20170150308).
Regarding claim 7 as applied to claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses the creation of the instructions includes receiving, at the server and from the client via the rules builder interface, a first context selection to serve as a trigger for a first rule and a response selection for the first rule (as detailed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the creation of the instructions further includes receiving, at the server and from the client via the rules builder interface, a location selection that specifies a custom geofenced zone as the first pre-defined geographic area.
Jones, however, a location selection that specifies a custom geofenced zone as the first pre-defined geographic area (Par. 156: Lines 2-6; A user is able to define a geofence via a GUI by outlining the perimeter on a map).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Jones’ GUI-based custom geofence creation (user-outlined polygon/area submitted to the server) into the rules platform of Jao in view of Kuusela in further view of Lidin in further view of Guichard so the server receives, via the same rules-builder interface, a location selection that specifies a custom geofenced zone as the predefined area—yielding predictable benefits of user flexibility, finer spatial accuracy, and a unified server-managed rule workflow.
Regarding claim 8 as applied to claim 7, Jao in view of Kussela in further view of Lidin in further view of Guichard disclose presenting selectable options when the client is making the first user context selection (as detailed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the creation of the instructions further includes:
creating, at the location infrastructure application and from the client, the custom geofenced zone on behalf of the client; and
presenting the custom geofenced zone as a selectable option when the client is making a first user selection.
Jones, however, discloses creating, at the location infrastructure application and from the client, the custom geofenced zone on behalf of the client (Par. 156: Lines 2-6; A user is able to define a geofence via a GUI by outlining the perimeter on a map); and
Presenting the custom geofenced zone as a selectable option (Par. 163: Lines 1-4; The user is able to select from a list of geofences).
Therefore, it would have been obvious to one of ordinary skill in the art to combine Jones’ on-platform geofence authoring and saved-zone listing with the rules UI of Jao in view of Kuusela in further view of Lidin in further view of Guichard so that the location infrastructure application creates the custom geofence on behalf of the client and then presents that saved zone as a selectable option during trigger selection—an expected design that improves reusability, reduces user error, and aligns creation and selection in a single interface.
Regarding claim 9 as applied to claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses a first user context selection (as detailed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the first pre-defined geographic area is a custom geofenced zone defined by one or more on-site beacons installed in the first pre-defined geographic area, and the first user context selection includes providing identifying information for the one or more on-site beacons.
Jones, however, discloses a pre-defined geographic area being a custom geofenced zone defined by one or more on-site beacons installed in the first pre-defined geographic area (Par. 182: Lines 1-6; A user can use a GUI to create a custom geofence by defining a radius around a beacon), and providing identifying information for the one or more on-site beacons (Par. 156: Lines 12-16; Identifying information for the one or more geofences are displayed via the GUI; The geofence is defined by the beacon so this corresponds to information on the beacon).
Therefore, it would have been obvious to one of ordinary skill in the art to extend the user-context selection of Jao in view of Kuusela in further view of Lidin in further view of Guichard with Jones’ beacon-defined geofences and GUI-exposed beacon identifiers so that the predefined area is a custom zone defined by one or more on-site beacons and the user context selection includes providing identifying information for those beacons—a routine substitution that enables indoor/precision coverage using known beacon IDs, with predictable improvements in reliability and deployment practicality.
Regarding claim 11 as applied to claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses instructions including receiving, at the server and from the client via the rules builder interface triggers and rules for a pre-defined geographic area (as detailed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the creation of the instructions further includes receiving, at the server and from the client via the rules builder interface, a place of interest (POI) selection that specifies a first POI from multiple places of interest (POIs) that are identified in a POI database associated with the location infrastructure application, and the first pre-defined geographic area is the first POI.
Jones, however, discloses a POI database and selectable POIs (Par. 182: Lines 6-15; Multiple POIs (dog park, house, fire hydrants) are available for selection), and POI as a predefined area (Par. 182: Lines 6-15; Multiple POIs (dog park, house, fire hydrants) are predefined areas).
Therefore, it would have been obvious to one of ordinary skill in the art to modify Jao’s server-hosted rules builder (as combined with Kussela/Lidin/Guichard) to incorporate Jones’s POI database and UI list/map so that the server presents multiple POIs and receives a user’s POI selection as the predefined geographic area; this is a predictable use of a known catalog input to specify the area that improves ease of configuration and accuracy by reusing stored POI coordinates, without changing the systems’ principle of operation.
Regarding claim 18 as applied to claim 16, the rejection of claim 7 addresses the limitations presented in claim 18. Therefore, the limitations of claim 18 have been addressed.
Regarding claim 19 as applied to claim 18, the rejection of claim 8 addresses the limitations presented in claim 19. Therefore, the limitations of claim 19 have been addressed.
Regarding claim 20 as applied to claim 16, the rejection of claim 9 addresses the limitations presented in claim 20. Therefore, the limitations of claim 20 have been addressed.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Horton et al. (US 20160261425, hereinafter Horton).
Regarding claim 12 as applied to claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses a first pre-defined geographic area (as disclosed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose wherein the first pre-defined geographic area is a region defined by one of a zip code, city, county, state, and country, and the first user context selection includes identification of that region.
Horton, however, discloses a geographic area defined by a city or county and a user context selection including identification of that region (Par. 648: Lines 4-6; Inputs that trigger conditional rules may be a city or a county). The remaining limitations were given no patentable weight due to the optional language “or”.
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Horton’s region-based selectors (e.g., city/county) into the rules-builder UI of Jao in view of Kussela in further view of Lidin in further view of Guichard so that, when defining the first user context, the server also receives identification of a pre-defined geographic region such as a city or county— a routine parameterization of the location field that predictably improves usability and policy scoping without altering the underlying trigger/response logic.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Lett (US 20170359188).
Regarding claim 13 in view of claim 1, Jao in view of Kussela in further view of Lidin in further view of Guichard discloses wherein the creation of the instructions further includes receiving, at the server and from the client via the rules builder interface, a condition for a trigger (as detailed in the rejection of claim 1).
Jao in view of Kussela in further view of Lidin in further view of Guichard does not disclose the creation of the instructions further including a time period selection for the first rule, the time period selection defining a window during which the conditions for the trigger selection must occur.
Lett, however, discloses the ability to choose a time period for which trigger conditions must occur (Par. 34: Lines 10-15; A user may specify that trigger conditions only apply during certain time periods).
Therefore, it would have been obvious to one of ordinary skill in the art to incorporate Lett’s time-window parameter into server-managed rules UI of Jao in view of Kussela in further view of Lidin in further view of Guichard so that, when receiving the trigger condition from the client, the server also receives a time-period selection that defines the window during which the trigger must occur—a routine enhancement in rule/automation systems that yields predictable benefits (scheduled applicability, fewer false positives, and policy control without changing core detection logic).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Jao et al. (US 20140351800, hereinafter Jao) in view of Kussela et al. (US 20130332279, hereinafter Kussela) in further view of Lidin et al. (US 20160269496, hereinafter Lidin) in further view of Guichard et al. (US 20050132305, hereinafter Guichard) in further view of Jones (US 20170150308) in further view of Vaynblat et al. (US 9648581, hereinafter Vaynblat).
Regarding claim 10 as applied to claim 9, Jao in view of Kussela in further view of Lidin in further view of Guichard in further view of Jones teaches a rules builder interface used to select a location that specifies a geofenced zone (as detailed in the rejection of claim 7), creating a custom geofenced zone and presenting the geofenced zone as a selectable option when the client is making the first user selection (as detailed in the rejection of claim 8) and a geofenced zone defined by one or more on-site beacons installed in the geographic area (as detailed in the rejection of claim 9).
Jao in view of Kussela in further view of Lidin in further view of Guichard in further view of Jones does not teach registering, at the location infrastructure application on behalf of the client, the one or more on-site beacons; and
presenting, via the rules builder interface and when the client is making the first user context selection, a list of selectable options, each selectable option corresponding to one registered on-site beacon.
Vaynblat, however, discloses registering on-site beacons (Col. 12: Lines 38-40; The systems backend sends the geofences to the system’s geofence SDK installed on the device; A backend maintaining geofence/beacon configs necessarily includes a registration step (creating entries for the beacons used to define zones)).
Therefore, it would have been obvious to one of ordinary skill in the art to augment Jao in view of Kussela in further view of Lidin in further view of Guichard in further view of Jones with Vaynblat’s backend/SDK beacon registry so that (i) beacons are registered in the backend (creating stored beacon entries used for zone definition) and (ii) the rules-builder UI simply lists those registered beacons as selectable options for the user to bind a rule to— a predictable integration that standardizes beacon management, reduces manual entry/error, and reuses the existing registry to drive configuration, without altering the combined system’s principle of operation.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FABIAN BOTELLO whose telephone number is (571)272-4439. The examiner can normally be reached Monday - Friday 8:30 am - 5:30 pm.
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, Wesley Kim can be reached at 571-272-7867. 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.
/FABIAN BOTELLO/Examiner, Art Unit 2648
/WESLEY L KIM/Supervisory Patent Examiner, Art Unit 2648
Prosecution Insights