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 .
Status of Claims
This action is in reply to the communications filed on 6/23/2025.
Claims 1-20 are currently pending and have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 6/23/2025 has been entered.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/23/2025 is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,367,523. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the instant application are anticipated by the claims of U.S. Patent No. 12,367,523.
Instant application and Patent No. 12,367,523 claim the same invention as follows:
Instant Application
Patent No. 12,367,523
1. A method comprising:
receiving from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant search term;
selecting a federated directory service wallet system interface to forward the request to, the selection based in part on the location information being within a predetermined radius of global positioning system coordinates of the federated directory service wallet system interface; and
forwarding the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device,
wherein the federated directory service wallet system interface is configured to:
in response to receiving the request:
translate the merchant search term into one or more classifications;
match directory data associated with the location information and the classifications to the request; and
return results that match the location information and the classifications to the mobile device via a wallet server.
1. A method comprising:
receiving from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant name;
selecting, based in part on the location information, a federated directory service wallet system interface to forward the request, wherein the federated directory service wallet system interface is integrated with at least one chamber of commerce and is selected based in part on the global positioning system coordinates of the mobile device matching global positioning system coordinates of a location of the federated directory service wallet system interface within a predetermined radius; and
forwarding the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device,
wherein the federated directory service wallet system interface is configured to:
in response to receiving the request from the federated directory service wallet system interface:
translate the merchant name into one or more classification codes;
match directory data associated with the location information and the classification codes to the request; and
return results that match the location information and the classification codes to the mobile device via a wallet server.
2. The method of claim 1, further comprising transmitting the directory data to the mobile device.
2. The method of claim 1, further comprising transmitting the directory data to the mobile device.
3. The method of claim 1, wherein the location information is cellular location information determined by the mobile device.
3. The method of claim 1, wherein the location information is cellular location information determined by the mobile device.
4. The method of claim 1, wherein the location information is based on request information entered into the mobile device.
4. The method of claim 1, wherein the location information is based on request information entered into the mobile device.
5. The method of claim 4, wherein the location information is based on a travel destination indicated in a calendar application on the mobile device.
5. The method of claim 4, wherein the location information is based on a travel destination indicated in a calendar application on the mobile device.
6. The method of claim 1, wherein the directory data comprises information comprising it least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
6. The method of claim 1, wherein the directory data comprises information comprising at least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
7. The method of claim 1, wherein the mobile device comprises one of a smartphone or tablet computer.
7. The method of claim 1, wherein the mobile device comprises one of a smartphone or tablet computer.
8. A system comprising:
a processor configured to:
receive from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant search term;
select a federated directory service wallet system interface to forward the request to, the selection based in part on the location information being within a predetermined radius of global positioning system coordinates of the federated directory service wallet system interface; and
forward the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, wherein the federated directory service wallet system interface is configured to:
in response to receiving the request:
translate the merchant search term into one or more classifications;
match directory data associated with the location information and the classifications to the request; and
return results that match the location information and the classifications to the mobile device via a wallet server.
8. A system comprising: a processor configured to:
receive from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant name; select, based in part on the location information, a federated directory service wallet system interface to forward the request, wherein the federated directory service wallet system interface is integrated with at least one chamber of commerce and is selected based in part on the global positioning system coordinates of the mobile device matching global positioning system coordinates of a location of the federated directory service wallet system interface within a predetermined radius; and
forward the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, wherein the federated directory service wallet system interface is configured to:
in response to receiving the request from the federated directory service wallet system interface:
translate the merchant name into one or more classification codes;
match directory data associated with the location information and the classification codes to the request; and return results that match the location information and the classification codes to the mobile device via a wallet server.
9. The system of claim 8, wherein the processor is further configured to transmit the directory data to the mobile device.
9. The system of claim 8, wherein the processor is further configured to transmit the directory data to the mobile device.
10. The system of claim 8, wherein the location information is cellular location information determined by the mobile device.
10. The system of claim 8, wherein the location information is cellular location information determined by the mobile device.
11. The system of claim 8, wherein the location information is based on request information entered into the mobile device.
11. The system of claim 8, wherein the location information is based on request information entered into the mobile device.
12. The system of claim 11, wherein the location information is based on a travel destination indicated in a calendar application on the mobile device.
12. The system of claim 11, wherein the location information is based on a travel destination indicated in a calendar application on the mobile device.
13. The system of claim 8, wherein the directory data comprises information comprising at least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
13. The system of claim 8, wherein the directory data comprises information comprising at least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
14. The system of claim 8, wherein the mobile device comprises one of a smartphone or tablet computer.
14. The system of claim 8, wherein the mobile device comprises one of a smartphone or tablet computer.
15. A non-transitory computer readable medium comprising program code that when executed by one or more processors is configured to cause the one or more processors to:
receive from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant search term;
select a federated directory service wallet system interface to forward the request to, the selection based in part on the location information being within a predetermined radius of global positioning system coordinates of the federated directory service wallet system interface; and
forward the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, wherein the federated directory service wallet system interface is configured to:
in response to receiving the request:
translate the merchant search term into one or more classifications;
match directory data associated with the location information and the classifications to the request; and
return results that match the location information and the classifications to the mobile device via a wallet server.
15. A non-transitory computer readable medium comprising program code that when executed by one or more processors is configured to cause the one or more processors to:
receive from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant name;
select, based in part on the location information, a federated directory service wallet system interface to forward the request, wherein the federated directory service wallet system interface is integrated with at least one chamber of commerce and is selected based in part on the global positioning system coordinates of the mobile device matching global positioning system coordinates of a location of the federated directory service wallet system interface within a predetermined radius; and
forward the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, wherein the federated directory service wallet system interface is configured to:
in response to receiving the request from the federated directory service wallet system interface:
translate the merchant name into one or more classification codes;
match directory data associated with the location information and the classification codes to the request; and
return results that match the location information and the classification codes to the mobile device via a wallet server.
16. The non-transitory computer readable medium of claim 15, further comprising program code configured to cause the one or more processors to transmit the directory data to the mobile device.
16. The non-transitory computer readable medium of claim 15, further comprising program code configured to cause the one or more processors to transmit the directory data to the mobile device.
17. The non-transitory computer readable medium of claim 15, wherein the location information is cellular location information determined by the mobile device.
17. The non-transitory computer readable medium of claim 15, wherein the location information is cellular location information determined by the mobile device.
18. The non-transitory computer readable medium of claim 15, wherein the location information is based on request information entered into the mobile device.
18. The non-transitory computer readable medium of claim 15, wherein the location information is based on request information entered into the mobile device.
19. The non-transitory computer readable medium of claim 15, wherein the location information is based on a travel
19. The non-transitory computer readable medium of claim 15, wherein the location information is based on a travel destination indicated in a calendar application on the mobile device.
20. The non-transitory computer readable medium of claim 15, wherein the directory data comprises information comprising at least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
20. The non-transitory computer readable medium of claim 15, wherein the directory data comprises information comprising at least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.
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 of this title, 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.
Claims 1-4, 6-11, 13-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. US 9934523 B1 to Brock in view of U.S. Patent Application No. US 2013/0166332 A1 to Hammad.
Regarding Claim 1, Brock discloses A method comprising:
receiving from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant search term; ([Col 4 Ln 65-Col 5 Ln 5] A user can use the example interface shown in FIG. 2 to issue a query to the user application, e.g. using search bar 204. In response to receiving the query, the user application can retrieve a list of merchants 212, [Col 6 Ln 30-35] the server can send a delta between information about merchants already stored in the on-device directory of the user device and information about merchants that are currently near the location of the user device,)
selecting a federated directory service wallet system interface to forward the request to, ([Col 5 Ln 15-30] The user application can contact a server of an associated payment service system (federated directory service wallet system) and can populate the on-device directory with merchants that have an account with the payment service system. The server of the payment service system can provide the user application with a list of merchants having accounts with the payment service system and who have opted-in to having their information used in this way. In some implementations, the server can also provide the user application with information obtained from other sources, for example, merchant information obtained by crawling resources on the Internet.) the selection based in part on the location information being within a predetermined radius of global positioning system coordinates of the federated directory service wallet system interface; and ([Col 5 Ln 40-45] The user application can display the default list of merchants as list of participating merchants that are within a particular distance of the user device. [Col 7 Ln 20-30] The server can compute distances between the location of the user device and each merchant in the merchant directory and select merchants that are within a threshold distance, e.g. merchants that are within 1 mile of the user device [Col 6 Ln 40-45] The user device provides a location update to the server (302). For example, the user device can determine its own location based on GPS information, cellphone data, wireless network data, or the like and provide the location information to the server.[Col 7 Ln 10-20] The server can maintain a merchant directory, which for example, can include the merchant information described above with reference to FIG. 2, including the merchant name, a merchant category, e.g., a merchant category code (MCC), a merchant location, e.g. an address or geographic coordinates, in addition to other types of merchant information.)
forwarding the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, ([Col 7 Ln 55-67] The server determines a delta between merchant information for the geographic region of the user device and merchant information stored on the device (308). The delta information can identify both (1) a set of merchants that should be added to the on-device directory, e.g. merchants that are near the current location of the user device, and (2) a set of merchants that should be removed from the on-device directory, e.g. merchants that were near the previous location of the user device but which are no longer near the current location of the user device.)
But does not explicitly disclose wherein the federated directory service wallet system interface is configured to: in response to receiving the request: translate the merchant search term into one or more classifications; match directory data associated with the location information and the classifications to the request; and return results that match the location information and the classifications to the mobile device via a wallet server.
Hammad, on the other hand, teaches wherein the federated directory service wallet system interface is configured to: in response to receiving the request: translate the merchant search term into one or more classifications; match directory data associated with the location information and the classifications to the request; and return results that match the location information and the classifications to the mobile device via a wallet server.. ([0246] classifying entity types in some embodiments of the SEWI, e.g., an Entity Type Classification ("ETC") component 3300. In some implementations, a server may apply one or more classification labels to each of the data records. For example, the server may classify the data records according to entity type, according to criteria such as, but not limited to: geo-political area, number of items purchased, and/or the like. The server may obtain transactions from a database that are unclassified, e.g., 3301, and obtain rules and labels for classifying the records, e.g., 3302. For example, the database may store classification rules, [0290] A user may type in an item in the search field 4912 to search and/or add an item to a cart 4911. A user may also use a voice activated shopping mode by saying the name or description of an item to be searched and/or added to the cart into a microphone 4913. In a further implementation, a user may also select other shopping options 4914 such as current items 4915, bills 4916, address book 4917, merchants 4918 and local proximity 4919. [0295] With reference to FIG. 49E, in some other embodiments, a user may select merchants 4918 from the list of options in the shopping mode to view a select list of merchants 4918a-e. In one implementation, the merchants in the list may be affiliated to the wallet, or have affinity relationship with the wallet. In another implementation, the merchants may include a list of merchants meeting a user-defined or other criteria. For example, the list may be one that is curated by the user, merchants where the user most frequently shops or spends more than an x amount of sum or shopped for three consecutive months, and/or the like. [0296] there may be a local proximity option 4919 which may be selected by a user to view a list of merchants that are geographically in close proximity to the user. For example, the list of merchants 4919a-e may be the merchants that are located close to the user. In one implementation, the mobile application may further identify when the user in a store based on the user's location.)
It would have been obvious to one of ordinary skill in the art to include in the method, as taught by Brock, the features, as taught by Hammad, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Brock, to include the teachings of Hammad, in order to facilitate use of a virtual wallet for conducting purchase transactions. (Hammad, [0099]).
Regarding Claim 2, Brock in view of Hammad teaches the method of claim 1.
Brock discloses further comprising transmitting the directory data to the mobile device..
([Col 7 Ln 55-67] The server determines a delta between merchant information for the geographic region of the user device and merchant information stored on the device (308). The delta information can identify both (1) a set of merchants that should be added to the on-device directory, e.g. merchants that are near the current location of the user device, and (2) a set of merchants that should be removed from the on-device directory, e.g. merchants that were near the previous location of the user device but which are no longer near the current location of the user device. [Col 6 Ln 30-35] the server can send a delta between information about merchants already stored in the on-device directory of the user device and information about merchants that are currently near the location of the user device.)
Regarding Claim 3, Brock in view of Hammad teaches the method of claim 1.
Brock discloses wherein the location information is cellular location information determined by the mobile device. ([Col 6 Ln 40-45] The user device provides a location update to the server (302). For example, the user device can determine its own location based on GPS information, cellphone data, wireless network data, or the like and provide the location information to the server.)
Regarding Claim 4, Brock in view of Hammad teaches the method of claim 1.
Brock discloses wherein the location information is based on request information entered into the mobile device. ([Col 1 Ln 40-45] receiving a search query for merchants located in the geographic region; [Col 6 Ln 40-45] The user device provides a location update to the server (302). For example, the user device can determine its own location based on GPS information, cellphone data, wireless network data, or the like and provide the location information to the server.)
Regarding Claim 6, Brock in view of Hammad teaches the method of claim 1.
Brock discloses wherein the directory data comprises information comprising it least one of a Standard Industrial Classification code, a North American Industry Classification System, and a merchant designated classification code.. ([Col 7 Ln 10-20] The server determines merchants in a geographic region based on the received location (304). The server can maintain a merchant directory, which for example, can include the merchant information described above with reference to FIG. 2, including the merchant name, a merchant category, e.g., a merchant category code (MCC) (merchant designated classification code), a merchant location, e.g. an address or geographic coordinates, in addition to other types of merchant information.)
Regarding Claim 7, Brock in view of Hammad teaches the method of claim 1.
Brock discloses wherein the mobile device comprises one of a smartphone or tablet computer. ([Col 3 Ln 30-35] the user device 102 can be a desktop computer, laptop computer, smartphone, or tablet computer.)
Regarding Claim 8, Brock discloses A system comprising: a processor configured to::
receive from a mobile device a request for merchant directory services comprising location information associated with the mobile device and a merchant search term; ([Col 4 Ln 65-Col 5 Ln 5] A user can use the example interface shown in FIG. 2 to issue a query to the user application, e.g. using search bar 204. In response to receiving the query, the user application can retrieve a list of merchants 212, [Col 6 Ln 30-35] the server can send a delta between information about merchants already stored in the on-device directory of the user device and information about merchants that are currently near the location of the user device,)
select a federated directory service wallet system interface to forward the request to, ([Col 5 Ln 15-30] The user application can contact a server of an associated payment service system (federated directory service wallet system) and can populate the on-device directory with merchants that have an account with the payment service system. The server of the payment service system can provide the user application with a list of merchants having accounts with the payment service system and who have opted-in to having their information used in this way. In some implementations, the server can also provide the user application with information obtained from other sources, for example, merchant information obtained by crawling resources on the Internet.) the selection based in part on the location information being within a predetermined radius of global positioning system coordinates of the federated directory service wallet system interface; and ([Col 5 Ln 40-45] The user application can display the default list of merchants as list of participating merchants that are within a particular distance of the user device. [Col 7 Ln 20-30] The server can compute distances between the location of the user device and each merchant in the merchant directory and select merchants that are within a threshold distance, e.g. merchants that are within 1 mile of the user device [Col 6 Ln 40-45] The user device provides a location update to the server (302). For example, the user device can determine its own location based on GPS information, cellphone data, wireless network data, or the like and provide the location information to the server.[Col 7 Ln 10-20] The server can maintain a merchant directory, which for example, can include the merchant information described above with reference to FIG. 2, including the merchant name, a merchant category, e.g., a merchant category code (MCC), a merchant location, e.g. an address or geographic coordinates, in addition to other types of merchant information.)
forward the request to the federated directory service wallet system interface to facilitate communications between the federated directory service wallet system interface and the mobile device, ([Col 7 Ln 55-67] The server determines a delta between merchant information for the geographic region of the user device and merchant information stored on the device (308). The delta information can identify both (1) a set of merchants that should be added to the on-device directory, e.g. merchants that are near the current location of the user device, and (2) a set of merchants that should be removed from the on-device directory, e.g. merchants that were near the previous location of the user device but which are no longer near the current location of the user device.)
But does not explicitly disclose wherein the federated directory service wallet system interface is configured to: in response to receiving the request: translate the merchant search term into one or more classifications; match directory data associated with the location information and the classifications to the request; and return results that match the location information and the classifications to the mobile device via a wallet server.
Hammad, on the other hand, teaches wherein the federated directory service wallet system interface is configured to: in response to receiving the request: translate the merchant search term into one or more classifications; match directory data associated with the location information and the classifications to the request; and return results that match the location information and the classifications to the mobile device via a wallet server. ([0246] classifying entity types in some embodiments of the SEWI, e.g., an Entity Type Classification ("ETC") component 3300. In some implementations, a server may apply one or more classification labels to each of the data records. For example, the server may classify the data records according to entity type, according to criteria such as, but not limited to: geo-political area, number of items purchased, and/or the like. The server may obtain transactions from a database that are unclassified, e.g., 3301, and obtain rules and labels for classifying the records, e.g., 3302. For example, the database may store classification rules, [0290] A user may type in an item in the search field 4912 to search and/or add an item to a cart 4911. A user may also use a voice activated shopping mode by saying the name or description of an item to be searched and/or added to the cart into a microphone 4913. In a further implementation, a user may also select other shopping options 4914 such as current items 4915, bills 4916, address book 4917, merchants 4918 and local proximity 4919. [0295] With reference to FIG. 49E, in some other embodiments, a user may select merchants 4918 from the list of options in the shopping mode to view a select list of merchants 4918a-e. In one implementation, the merchants in the list may be affiliated to the wallet, or have affinity relationship with the wallet. In another implementation, the merchants may include a list of merchants meeting a user-defined or other criteria. For example, the list may be one that is curated by the user, merchants where the user most frequently shops or spends more than an x amount of sum or shopped for three consecutive months, and/or the like. [0296] there may be a local proximity option 4919 which may be selected by a user to view a list of merchants that are geographically in close proximity to the user. For example, the list of merchants 4919a-e may be the merchants that are located close to the user. In one implementation, the mobile application may further identify when the user in a store based on the user's location.)
It would have been obvious to one of ordinary skill in the art to include in the method, as taught by Brock, the features, as taught by Hammad, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Brock, to include the teachings of Hammad, in order to facilitate use of a virtual wallet for conducting purchase transactions. (Hammad, [0099]).
Claim 9 recites a system comprising substantially similar limitations as claim 2. The claim is rejected under substantially similar grounds as claim 2.
Claim 10 recites a system comprising substantially similar limitations as claim 3. The claim is rejected under substantially similar grounds as claim 3.
Claim 11 recites a system comprising substantially similar limitations as claim 4. The claim is rejected under substantially similar grounds as claim 4.
Claim 13 recites a system comprising substantially similar limitations as claim 6. The claim is rejected under substantially similar grounds as claim 6.
Claim 14 recites a system comprising substantially similar limitations as claim 7. The claim is rejected under substantially similar grounds as claim 7.
Claim 15 recites a non-transitory computer readable medium comprising program code comprising substantially similar limitations as claim 8. The claim is rejected under substantially similar grounds as claim 8.
Claim 15 recites a non-transitory computer readable medium comprising program code comprising substantially similar limitations as claim 8. The claim is rejected under substantially similar grounds as claim 8.
Claim 16 recites a non-transitory computer readable medium comprising substantially similar limitations as claim 2. The claim is rejected under substantially similar grounds as claim 2.
Claim 17 recites a non-transitory computer readable medium comprising substantially similar limitations as claim 3. The claim is rejected under substantially similar grounds as claim 3.
Claim 18 recites a non-transitory computer readable medium comprising substantially similar limitations as claim 4. The claim is rejected under substantially similar grounds as claim 4.
Claim 20 recites a non-transitory computer readable medium comprising substantially similar limitations as claim 6. The claim is rejected under substantially similar grounds as claim 6.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. US 9934523 B1 to Brock and U.S. Patent Application No. US 2013/0166332 A1 to Hammad in view of U.S. Patent Application No. US 2015/0134413 A1 to Deshpande.
Regarding Claim 5, Brock in view of Hammad teaches the method of claim 4.
However the combination of Brock and Hammad does not explicitly teach wherein the location information is based on a travel destination indicated in a calendar application on the mobile device
Deshpande, on the other hand, teaches wherein the location information is based on a travel destination indicated in a calendar application on the mobile device. ([0084] The external, geospatial, temporal, and contextual data sources 212 are not particularly limited and can include data from shopper location traces (e.g., mobile app location check-ins, commute data, local event calendars, etc.), local sports teams, school lunch menus, personal calendars, (e.g., travel, work at home indication, etc.))
It would have been obvious to one of ordinary skill in the art to include in the method, as taught by Brock and Hammad, the features as taught by Deshpande, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. It further would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination, to include the teachings of Deshpande, in order to tailor offers to customers (Deshpande, [0003]).
Claim 12 recites a system comprising substantially similar limitations as claim 5. The claim is rejected under substantially similar grounds as claim 5.
Claim 19 recites a non-transitory computer readable medium comprising substantially similar limitations as claim 5. The claim is rejected under substantially similar grounds as claim 5.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Michelle T. Kringen whose telephone number is (571)270-0159. The examiner can normally be reached M-F: 11am-7pm.
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, Marissa Thein can be reached at (571)272-6764. 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.
/MICHELLE T KRINGEN/Primary Examiner, Art Unit 3689
Prosecution Insights