DETAILED ACTION
Claims 1-20 are pending in the application.
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 .
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.
Examiner’s Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 17/068,611, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application.
Specifically, Application No. 17/068,611 does not provide support for the limitations “defining, by the server and based on the geolocation information, geolocation boundaries and one or more workflows to associate with the contextual zone” and “executing, by the server, the one or more workflows while the present location of the mobile device is within the geolocation boundaries” recited in claim 1, and/or the similar limitations recited in claims 18 and 20.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The abstract of the disclosure is objected to because it uses phrases which can be implied, such as “Technologies disclosed herein are directed to”. A corrected abstract of the disclosure is required and must be presented on a separate sheet, apart from any other text. See MPEP § 608.01(b).
The disclosure is objected to because of the following informalities:
The instant application is a continuation-in-part of U.S. Patent Application No. 17/368,454, which is now issued as U.S. Patent No. 11,751,123 B2 on September 5, 2023. Both this patent number and the issue date must be disclosed in the first paragraph of the specification and/or with the Application Data Sheet.
Appropriate corrections are required. Applicant is advised to review the entire disclosure for further needed corrections.
Claim Rejections - 35 USC § 112(b)
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 3-8 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 3 recites the limitation "the user interface" in line 1. There is insufficient antecedent basis for this limitation in the claim. Neither claim 3 nor claim 1 recite a user interface prior to this limitation. As such, it is not clear if this limitation is referring to “a user interface” or if claim 3 should have been depending on claim 2 which discloses “a user interface”.
For the following analysis, the Examiner will consider claim 3 as depending on claim 2 and the limitation “the user interface” in claim 3 as referring to “a user interface” recited in claim 2.
Claims 4-8 inherit the features of claim 3 and are rejected accordingly.
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 18-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 18-19 are directed to “one or more computer-readable storage media” which is not limited to non-transitory embodiments. Furthermore, the specification describes implementing such media in transitory formats, such as in paragraph [0027].
Therefore, the “one or more computer-readable storage media” recited in claims 18-19 encompasses transitory embodiments which are non-statutory. See MPEP §2106.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-4, 6, 8-12, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rahnama (US 2013/0212130 A1) in view of Chmaytelli et al. (US 2006/0223494 A1; hereinafter Chmaytelli).
With respect to claim 1, Rahnama teaches: A computer-implemented method, comprising:
receiving, by a server (see e.g. Rahnama, Fig. 1: “Zone Management System 130”; and paragraph 53: “server based zone management systems”) and from [a control application of] a mobile device (see e.g. Rahnama, Fig. 1: “Electronic Device in Zone”) of a user (see e.g. Rahnama, paragraph 77: “device users”), an indication to create a contextual zone (see e.g. Rahnama, paragraph 58: “contextually relevant to the zone 110”) to associate with the mobile device (see e.g. Rahnama, paragraph 58: “When an electronic device 120, a cell phone for example, is found to be contextually relevant to the zone 110, the zone management system 130 can ensure the electronic device 120 can participate with the instantiated zone 110”; paragraph 76: “when an electronic device is considered to fall within the context of the airport”; paragraph 79: “electronic device 320 captures image data representative of zone marker 310. The image data, along with other device attributes 323, can be sent to zone server 350”; and paragraph 83: “zone server 350 is configured to obtain device attributes 323, which can include image data representative of zone marker 310, from the electronic device 320”), the indication including geolocation information (see e.g. Rahnama, paragraph 84: “GPS coordination, triangulation”) identifying a present location of the mobile device (see e.g. paragraph 76: “when an electronic device is considered to fall within the context of the airport (i.e., being physically located at the address of the airport or within an airport-defined geo-fence)”; and paragraph 83: “device attributes can include device identify, device sensor data (e.g., GPS coordination, triangulation”);
defining, by the server and based on the geolocation information (see e.g. Rahnama, paragraph 83: “server 350 can use device attributes 323”), geolocation boundaries (see e.g. Rahnama, paragraph 57: “zone could comprise zone context criteria that depend on geo-coordinate attributes, possibly including a geo-fence”; paragraph 58: “zone 110 has been defined and instantiated to have an extent over a geographical region”; paragraph 83: “server 350 can use device attributes 323 to determine if the device is contextually relevant to one or more zones 395”; and paragraph 85: “zone server 350 can detect the electronic device 320 as being contextually relevant to the zone 395 by comparing the device attributes 323 to the zone's context criteria. In a simple example as illustrated in FIG. 3, the zone criteria could include a geographic boundary based on geographic coordinates, information from zone marker 310, or other factors in the attributes space. If the GPS coordinates (i.e., device attributes) of the electronic device falls within an attribute space boundary of one or more zones 395, then the device 320 can be considered as being relevant to the zone”) and one or more workflows (see e.g. Rahnama, paragraph 57: “one or more context-based services”; and paragraph 58: “defined services or applications”; and paragraph 94: “persistent services 393”) to associate with the contextual zone (see e.g. Rahnama, paragraph 57: “zone provides access to one or more context-based services”; paragraph 58: “zone 110 has been defined and instantiated to have an extent over a geographical region and to comprise one or more defined services or applications offered through zone server 150”; and paragraph 94: “Once the zone server 350 detects that the electronic device is contextually relevant to the zone, the zone server configures the electronic device 320 to participate with persistent services 393 according to the zone criteria (e.g., zone context, zone profiles, roles, etc.) and the device attributes 323”); and
executing, by the server, the one or more workflows while the present location of the mobile device is within the geolocation boundaries (see e.g. Rahnama, paragraph 94: “Once the zone server 350 detects that the electronic device is contextually relevant to the zone, the zone server configures the electronic device 320 to participate with persistent services 393”; paragraph 95: “consider a scenario where a passenger enters an airport zone. The corresponding zone server can activate service-type handlers on the passenger's smart phone for check-in, directions, departure times, arrival information, or other services. Once the handlers are activated, associated icons or other indicators (e.g., visual, audio, tactile, etc.) can be presented to the passenger on the display of electronic device 320”; and paragraph 125).
Even though Rahnama discloses a thin client on the electronic device communicating with the server (see e.g. Rahnama, paragraph 94), does not explicitly disclose this client sending geolocation information to the server.
However, Chmaytelli teaches:
a control application of (see e.g. Chmaytelli, paragraph 61: “a CAM enabled client device can periodically report the location of the client device or execute an application to provide location data to a remote server that can calculate the location of the client device”)
Rahnama and Chmaytelli are analogous art because they are in the same field of endeavor: managing location-based services for client devices. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Chmaytelli. The motivation/suggestion would be to divide the workload on the client device by enabling the thin client application on the device to send the geolocation information (see e.g. Rahnama, paragraph 94; and Chmaytelli, paragraph 61); thus improving the overall processing efficiency of the client device.
With respect to claim 2, Rahnama as modified teaches: The method of claim 1, further comprising, displaying, on a user interface of the server (see e.g. Rahnama, Fig. 1: “Zone Management Interface 170”), information associated with the contextual zone (see e.g. Rahnama, paragraph 61: “Zone management systems 130 preferably include one or more zone management interfaces 170 through which zone managers (e.g., zone owners 175) can construct or manage their zones via a zone management server 180… zone management interface 170 is configured to offer the zone manager 175 many zone management functions. Example zone management functions include zone creation, zone editing, zone deletion, zone activation, zone deactivation, zone synchronization, zone service synchronization, zone replication, service definition, zone criteria definition, context definition, context plug-in management, electronic device control, electronic device management, electronic device native application management, zone role definition, zone profile definition, paying zone fees, bidding on zones, auctioning zones, attribute space definition, or other types of management or administration functions”).
With respect to claim 3, Rahnama as modified teaches: The method of claim 1, wherein the user interface is a map (see e.g. Rahnama, paragraph 62: “the zone manager 175 can be presented with a map”) providing the present location of the mobile device (see e.g. Rahnama, paragraph 63: “zone owners 175 might wish to bind their zones to a specific coordinate or even to an object… zone 110 could be bound relative to the GIS coordinates of a person's cell phone”), wherein the user interface further provides information associated with the user (see e.g. Rahnama, paragraph 63: “ bind their zones to a specific coordinate or even to an object (e.g., emergency vehicle, a moving object, person, etc.). For example, zone 110 could be bound relative to the GIS coordinates of a person's cell phone”), and wherein the user interface provides a communication interface for sending notifications (see e.g. Rahnama, paragraph 64: “promotional information”) to the user (see e.g. Rahnama, paragraph 64: “owner 175 of zone 110 around a shopping mall might allow a shop owner to advertise in the zone. The zone owner 175 can create a new service for the shop owner where the new service provides promotional information to shoppers in the mall. As soon as the new service is instantiated, the zone server can push the promotional information to all participants in the mall”).
With respect to claim 4, Rahnama as modified teaches: The method of claim 3, wherein one of the one or more workflows comprises a contact hierarchy (see e.g. Rahnama, paragraph 135: “colleagues… close friends”) for receiving alerts relating to the user of the mobile device (see e.g. Rahnama, paragraph 135: “Depending on a current relationship in the zone between participants, their privacy can be enforced. For example, when an employee is leaving an office zone after a day of work, colleagues are notified that the employee is out of the office while close friends are informed that the employee will be home soon”).
With respect to claim 6, Rahnama as modified teaches: The method of claim 4, further comprising:
detecting an event within the geolocation boundaries (see e.g. paragraph 123: “zone can be instantiated so that is bound to a moving vehicle, an ambulance for example. The instantiated zone can be deployed within the moving vehicle, or instantiated on a remote zone server that tracks movement of the vehicle”) pertaining to an escalation situation (see e.g. Rahnama, paragraph 57: “A zone can be defined in terms of criteria that depend on a multi-dimensional attribute space. The attribute space can be used to define a zone's extent across the real-world in terms of attribute values within the attribute space. The attribute space can comprise many different dimensions including… motion (e.g., speed, velocity, acceleration, jerk, etc.)”; and paragraph 123: “tracks movement of the vehicle… speed”); and
sending an alert relating to the escalation situation to a mobile device of a first user (see e.g. Rahnama, paragraph 123: “alert proximate vehicles, other zones, or zone services”) in the contact hierarchy (see e.g. Rahnama, paragraph 123: “zone can be considered a dynamic or time varying object. For example, an emergency vehicle represented as a zone, can alert proximate vehicles, other zones, or zone services on its location and speed”).
With respect to claim 8, Rahnama as modified teaches: The method of claim 4, further comprising:
assigning a priority (see e.g. Rahnama, paragraph 135: “privacy rules”) to each of a plurality of users within the contact hierarchy for receiving the alerts relating to the user of the mobile device (see e.g. Rahnama, paragraph 135: “a zone or its services can be labeled as private, protected, or public… interactions among zone participants or zone services can be governed by privacy rules as illustrated in FIG. 21. Depending on a current relationship in the zone between participants, their privacy can be enforced. For example, when an employee is leaving an office zone after a day of work, colleagues are notified that the employee is out of the office while close friends are informed that the employee will be home soon”).
With respect to claim 9, Rahnama as modified teaches: The method of claim 1, wherein receiving the indication to create a contextual zone comprises receiving a manual specification to create the contextual zone by the user of the mobile device (see e.g. Rahnama, paragraph 57: “ users or devices can participate with the zone if permitted where the user can participate with a zone based on… manual selection”; and paragraph 90: “if a user selects a geographical boundary that includes one or more law offices, the zone management server can recommend a law office ontology suitable for construction a law office zone. The ontology can comprise example user profiles, user relationships, office profiles, or other information”).
With respect to claim 10, Rahnama as modified teaches: The method of claim 1, wherein receiving the indication to create the contextual zone comprises receiving, [from the control application], an indication of sensor activity associated with an environment external to the mobile device of the user (see e.g. Rahnama, paragraph 25: “zone server can obtain device attributes from the electronic devices, image data or sensor data for example, and compare them to the properties of one or more zone objects to determine if the electronic devices are contextually relevant to the zones”; and paragraph 83: “zone server 350 can obtain the device attributes 323 over the connection from the electronic device 320. Example device attributes can include… device sensor data (e.g., GPS coordination, triangulation, accelerometer, heading, audio, image, video, etc.)”).
Rahnama does not but Chmaytelli teaches:
from the control application (see e.g. Chmaytelli, paragraph 61: “a CAM enabled client device can periodically report the location of the client device or execute an application to provide location data to a remote server that can calculate the location of the client device”)
Rahnama and Chmaytelli are analogous art because they are in the same field of endeavor: managing location-based services for client devices. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Chmaytelli. The motivation/suggestion would be to divide the workload on the client device by enabling the thin client application on the device to send the geolocation information (see e.g. Rahnama, paragraph 94; and Chmaytelli, paragraph 61); thus improving the overall processing efficiency of the client device.
With respect to claim 11, Rahnama as modified teaches: The method of claim 10, wherein receiving the indication to create the contextual zone comprises receiving, [from the control application], an indication that the mobile device has exited a vehicle (see e.g. Rahnama, paragraph 123: “further the zone can be instantiated so that is bound to a moving vehicle, an ambulance for example. The instantiated zone can be deployed within the moving vehicle”; paragraph 124: “As the passenger leaves the "Terminal 1 Zone"”; and paragraph 135: “when an employee is leaving an office zone”).
Since Rahnama discloses a vehicle as a zone (see e.g. Rahnama, paragraph 123) and detecting a user exiting from various zones (see e.g. Rahnama, paragraphs 124, 135), it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to realize a user exiting a vehicle zone as one of the contextual information that is handled by the zone management system. The motivation would be to improve the contextual evaluation mechanism of the system.
Furthermore, Rahnama does not but Chmaytelli teaches:
from the control application (see e.g. Chmaytelli, paragraph 61: “a CAM enabled client device can periodically report the location of the client device or execute an application to provide location data to a remote server that can calculate the location of the client device”)
Rahnama and Chmaytelli are analogous art because they are in the same field of endeavor: managing location-based services for client devices. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Chmaytelli. The motivation/suggestion would be to divide the workload on the client device by enabling the thin client application on the device to send the geolocation information (see e.g. Rahnama, paragraph 94; and Chmaytelli, paragraph 61); thus improving the overall processing efficiency of the client device.
With respect to claim 12, Rahnama as modified teaches: The method of claim 10, wherein receiving the indication to create the contextual zone comprises receiving an indication from the control application that the mobile device has connected to a wireless network (see e.g. Rahnama, paragraph 83: “electronic device 320 can establish a connection (e.g., a TCP/IP connection, a session, an asynchronous connection, etc.) with a zone server 350, possibly via a thin client or operating system module, and keeps the connection open. Once the connection is established, the device 320 and zone server 350 can maintain the connection. When context dictates, the zone server 350 can push service information from persistent services 393 or other sources to device 320… As the device 320 moves from one zone to another zone, the device can 320 maintain the same connection to a zone server 350 or establish a new connection with a new zone server, possibly based on a hand-off algorithm”).
With respect to claim 16, Rahnama as modified teaches: The method of claim 1, wherein defining the geolocation boundaries and the one or more workflows comprises defining one or more conditions for exiting the context zone (see e.g. Rahnama, paragraph 124: “when the device falls outside a contextual boundary of the zone, the service-type handlers can be deactivated or removed from presentation so that they are no longer available to the user… As the passenger leaves the "Terminal 1 Zone", the service indicators depopulate”; and paragraph 135: “when an employee is leaving an office zone after a day of work, colleagues are notified that the employee is out of the office while close friends are informed that the employee will be home soon”).
With respect to claim 17, Rahnama as modified teaches: The method of claim 1, further comprising:
receiving, by the server, additional geolocation data from the mobile device (see e.g. Rahnama, paragraph 83: “As the device 320 moves from one zone to another zone, the device can 320 maintain the same connection to a zone server 350 or establish a new connection with a new zone server, possibly based on a hand-off algorithm. Regardless of the connection, the zone server 350 can obtain the device attributes 323 over the connection from the electronic device 320. Example device attributes can include… GPS coordination, triangulation”; paragraph 137: “Electronic devices can move from zone to zone”); and
extending, by the server, the defined geolocation boundaries of the contextual zone based on the additional geolocation data received from the mobile device (see e.g. Rahnama, paragraph 137: “Electronic devices can move from zone to zone. In such scenarios, zone's can employ one or more hand-off algorithms designed to hand-off an electronic device from one zone to another zone assuming a hand-off is required. Such an approach is useful when multiple zones overlap or neighbor each other but offer differing services. For example, in an airport a terminal or gate zone might hand off a passenger's electronic device to a duty-free shop zone when the passenger goes shopping, thus giving the shop zone higher precedence over the terminal zone”; and paragraph 124).
With respect to claims 18 and 19: Claims 18 and 19 are directed to one or more computer-readable media storing instructions which, when executed on a processor, causes a server to implement active steps corresponding to the method disclosed in claims 1 and 3, respectively; please see the rejections directed to claims 1 and 3 above which also cover the limitations recited in claims 18 and 19. Note that, Rahnama also discloses a computer-readable media storing instructions for execution on a processor to implement the method disclosed in claims 1 and 3 (see e.g. Rahnama, paragraph 53).
With respect to claim 20, Rahnama teaches: A computer-implemented method, comprising:
sending, from [a control application executing on] a mobile device (see e.g. Rahnama, Fig. 1: “Electronic Device in Zone”) of a user (see e.g. Rahnama, paragraph 77: “device users”), an indication to create a contextual zone (see e.g. Rahnama, paragraph 58: “contextually relevant to the zone 110”) to associate with the mobile device to a server (see e.g. Rahnama, Fig. 1: “Zone Management System 130”; paragraph 58: “When an electronic device 120, a cell phone for example, is found to be contextually relevant to the zone 110, the zone management system 130 can ensure the electronic device 120 can participate with the instantiated zone 110”; paragraph 76: “when an electronic device is considered to fall within the context of the airport”; paragraph 79: “electronic device 320 captures image data representative of zone marker 310. The image data, along with other device attributes 323, can be sent to zone server 350”; and paragraph 83: “zone server 350 is configured to obtain device attributes 323, which can include image data representative of zone marker 310, from the electronic device 320”), the indication including geolocation information (see e.g. Rahnama, paragraph 84: “GPS coordination, triangulation”) identifying a present location of the mobile device (see e.g. paragraph 76: “when an electronic device is considered to fall within the context of the airport (i.e., being physically located at the address of the airport or within an airport-defined geo-fence)”; and paragraph 83: “device attributes can include device identify, device sensor data (e.g., GPS coordination, triangulation”);
defining, by the control application (see e.g. Rahnama, paragraph 94: “a thin zone client or operating system module”), the contextual zone based on the geolocation boundaries and information sent by the server in response to the indication (see e.g. Rahnama, paragraph 94: “The zone server 350 can configure the electronic devices to participate in the zone through various methods. In some embodiments, the device 320 can comprise a thin zone client or operating system module that communicatively couples with the zone server 350 and that comprises service-type handlers. The service-type handlers allow the device 320 to participate with known types of services offered by zones. When the zone server 350 sends a signal over the network 115 to the device 320, the service-type handlers can be activated so that the handlers are receptive to the services 393 of the zone”); and
executing, by the control application, one or more workflows associated with the defined contextual zone (see e.g. Rahnama, paragraph 94: “the device 320 can comprise a thin zone client or operating system module that communicatively couples with the zone server 350 and that comprises service-type handlers. The service-type handlers allow the device 320 to participate with known types of services offered by zones. When the zone server 350 sends a signal over the network 115 to the device 320, the service-type handlers can be activated so that the handlers are receptive to the services 393 of the zone”) while the present location of the mobile device is within the geolocation boundaries (see e.g. Rahnama, paragraph 95: “Once the handlers are activated, associated icons or other indicators (e.g., visual, audio, tactile, etc.) can be presented to the passenger on the display of electronic device 320. Similarly, when electronic device 320 is determined to be no longer contextually relevant, the icons or indicators can be hidden or removed from the passenger's view”; and paragraph 124: “The handlers can be activated so they become receptive to the zone upon becoming contextually relevant. When activated, corresponding icons or other indicators can be presented to the user to indicate the presence of corresponding services. Similarly, when the device falls outside a contextual boundary of the zone, the service-type handlers can be deactivated or removed”).
Even though Rahnama discloses a thin client on the electronic device communicating with the server (see e.g. Rahnama, paragraph 94), does not explicitly disclose this client sending geolocation information to the server.
However, Chmaytelli teaches:
a control application executing on (see e.g. Chmaytelli, paragraph 61: “a CAM enabled client device can periodically report the location of the client device or execute an application to provide location data to a remote server that can calculate the location of the client device”)
Rahnama and Chmaytelli are analogous art because they are in the same field of endeavor: managing location-based services for client devices. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Chmaytelli. The motivation/suggestion would be to divide the workload on the client device by enabling the thin client application on the device to send the geolocation information (see e.g. Rahnama, paragraph 94; and Chmaytelli, paragraph 61); thus improving the overall processing efficiency of the client device.
Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Rahnama in view of Chmaytelli as applied to claim 4 above, and further in view of McGovern (US 6,909,359 B1).
With respect to claim 5, Rahnama as modified teaches: The method of claim 4, further comprising:
sending, via the user interface (see e.g. Rahnama, paragraph 61: “zone management interface 170 is configured to offer the zone manager 175 many zone management functions. Example zone management functions include… service definition… electronic device control, electronic device management, electronic device native application management”; and paragraph 71: “services 293 can cover a broad spectrum of capabilities or responsibilities of the zone. Example services can include… notifications”), a notification to the mobile device of the user (see e.g. Rahnama, paragraph 137: “send an urgent notification”; and paragraph 71: “more zone services 293…notifications”),
sending an alert relating to the user of the mobile device to a mobile device of a user in the contact hierarchy (see e.g. Rahnama, paragraph 135: “Depending on a current relationship in the zone between participants, their privacy can be enforced. For example, when an employee is leaving an office zone after a day of work, colleagues are notified that the employee is out of the office while close friends are informed that the employee will be home soon”).
Rahnama does not but McGovern teaches:
the notification prompting the mobile device for a response (see e.g. McGovern, column 7, lines 3-4: “require the patient to log a response within a specified time”); and
after a predetermined period of a lack of response from the mobile device (see e.g. McGovern, column 7, lines 3-9: “require the patient to log a response within a specified time of a scheduled regimen event. For example, a diabetes patient could be required to provide feedback about diet or insulin concentration at specified times. If the patient does not report, the connectivity server can be made functional to alert health care providers or emergency contact personnel”),
Rahnama and McGovern are analogous art because they are in the same field of endeavor: managing communications between client and server devices, including contextual notifications/alerts. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of McGovern. The motivation/suggestion would be to handle potential emergency situations (see e.g. McGovern, column 7, lines 38-55); thus improving the overall applicability of the system.
With respect to claim 7, Rahnama as modified teaches: The method of claim 6, further comprising:
Rahnama does not but McGovern teaches:
after a predetermined period of a lack of response from the mobile device of the first user, sending an alert relating to the escalation situation to a mobile device of a second user in the contact hierarchy (see e.g. McGovern, column 7, lines 3-9: “require the patient to log a response within a specified time of a scheduled regimen event. For example, a diabetes patient could be required to provide feedback about diet or insulin concentration at specified times. If the patient does not report, the connectivity server can be made functional to alert health care providers or emergency contact personnel”).
Rahnama and McGovern are analogous art because they are in the same field of endeavor: managing communications between client and server devices, including contextual notifications/alerts. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of McGovern. The motivation/suggestion would be to handle potential emergency situations (see e.g. McGovern, column 7, lines 38-55); thus improving the overall applicability of the system.
Claims 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rahnama in view of Chmaytelli as applied to claim 1 above, and further in view of Gauglitz (US 2018/0007149 A1).
With respect to claim 13, Rahnama as modified teaches: The method of claim 1,
Rahnama does not but Gauglitz teaches:
further comprising, receiving, from the control application (see e.g. Gauglitz, paragraph 12: “a software application, an instance of which is installed on each of said plurality of mobile technology platforms”) an indication that the contextual zone is invalid (see e.g. Gauglitz, Fig. 2: “205”; paragraph 12: “a software application, an instance of which is installed on each of said plurality of mobile technology platforms, which establishes a dynamic geofence and an exclusion zone around the host mobile technology platform, and which tracks the current location of the host mobile technology platform”; and paragraph 21: “When another mobile technology platform is within the exclusion zone 205 and is equipped with an instance of the software, the software may preclude that mobile technology platform from acquiring media of the target, from associating any captured media with the target, and/or from attributing any captured media to a particular user”).
Rahnama and Gauglitz are analogous art because they are in the same field of endeavor: managing operations of a mobile device based on the device’s location in relation to particular zones. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Gauglitz. The motivation/suggestion would be to improve privacy management associated with the mobile devices (see e.g. Gauglitz, paragraph 22).
With respect to claim 14, Rahnama as modified teaches: The method of claim 13, further comprising,
Rahnama does not but Gauglitz teaches:
adding the contextual zone to a list of invalid contextual zones (see e.g. Gauglitz, paragraph 12: “a software application, an instance of which is installed on each of said plurality of mobile technology platforms, which establishes a dynamic geofence and an exclusion zone around the host mobile technology platform”; paragraph 32: “exclusion zones described herein may be established in a variety of ways”; and paragraph 33: “boundaries of a geofence or exclusion zone may be periodically determined by one or more servers or other devices external to a mobile technology platform. In such embodiments, the boundaries of a geofence or exclusion zone may be periodically transmitted to the mobile technology platform, or may be stored on the external device (or devices) for use in determining whether captured media should be associated with the geofence”).
Rahnama and Gauglitz are analogous art because they are in the same field of endeavor: managing operations of a mobile device based on the device’s location in relation to particular zones. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Rahnama with the teachings of Gauglitz. The motivation/suggestion would be to improve privacy management associated with the mobile devices (see e.g. Gauglitz, paragraph 22).
Allowable Subject Matter
Claim 15 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
CONCLUSION
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Bailey et al. (US 8,618,913 B1) discloses a server device 34 that manages rules or policies of a mobile device based upon geographic location by updating the rules or policies stored by the mobile device periodically as geographic areas of the mobile device are added or deleted (see column 3, lines 41-60).
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30.
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, Kevin L Young can be reached at (571) 270-3180. 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.
/UMUT ONAT/Primary Examiner, Art Unit 2194