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 amendment filed on 4/13/2026.
Claims 44-45 have been amended and are hereby entered.
Claims 37-56 are currently pending, with Claims 44-49 having been examined and Claims 37-43 and 50-56 withdrawn without traverse.
This action is made FINAL.
Information Disclosure Statement
The reference listed in the IDS dated 5/07/2026 has been considered.
Response to Applicant’s Arguments
Claim Rejections – 35 USC § 112
The present amendments to the claims obviate the previous 112(a) rejections thereto; therefore, these rejections are withdrawn. Examiner notes that, depending upon the interpretation of the claims as presently amended, new 112(a) new matter rejections could easily have been given; however, the claims are instead interpreted to avoid these issues via various 112(b) indefiniteness rejections below (within which the issues of lack of support are discussed). As per the last several rounds of amendments/remarks and Office Actions filed in relation thereto, Applicant has seemed to develop a pattern of either failing to consider support in the original disclosure or failing to consider the full scope of what is claimed in view of what is supported in the original disclosure. This approach will not be effective in advancing prosecution and will continue to cause similar issues if continued in the future.
The present amendments the claims obviate the previous 112(b) rejection thereto; therefore, this rejection is withdrawn.
Claim Rejections – 35 USC § 101
Applicant’s arguments regarding the 101 analysis have been considered and are unpersuasive.
Applicant’s first several arguments regarding 101 appear to bounce back and forth between Step 2A, Prong One and Prong Two standards seemingly without rhyme or reason, and further continues to use the language “directed to” in a manner other than its particular use within the 101 subject matter eligibility analysis (e.g., “[t]hese limitations are not directed to organizing human activity;” “claim 44 is directed to a specific improvement in computerized reservation platforms”) in similar fashion as to what was called out in the previous Office Action. For the sake of clarity, Examiner addresses these arguments not in the order in which they are presented, but rather in the order of the steps of the 101 subject matter eligibility analysis. Applicant is encouraged to review at least MPEP 2106.04 and the various subsections thereof to properly understand the distinct steps of this analysis, the discrete standards of these steps, and the meaning of language such as “directed to” within this analysis.
Regarding Step 2A, Prong One, Applicant argues that “claim 44 recites features that enable generating a temporary reservation for a selected resource, and updating an inventory to indicate the resource is unavailable for the requested time, thereby preventing another user from completing a reservation for the same resource. These limitations are not directed to organizing human activity. Rather, they define a computer-implemented mechanism for controlling access to shared resources in a multi-user environment. That is, preventing conflicting reservations requires maintaining a time-dependent inventory state, and enforcing mutual exclusion across concurrent user requests. This is not a fundamental economic practice, but a technical problem arising in computerized reservation platforms. Accordingly, claim 44 is not directed to an abstract idea.” Examiner disagrees. Generating a temporary reservation for a resource and updating an inventory to reflect this reservation/indicate that the resource in question is unavailable for separate reservations during the reservation period is absolutely a certain method of organizing human activity, at the very least in the form of a commercial or legal activity. Indeed, the reservation of a reservable resource (and, consequently, prevention of its use by others during the span of that reservation, which is the entire purpose of a reservation) is so fundamentally commercial in nature that Examiner cannot fathom how Applicant concludes otherwise. This is true of a “temporary” reservation or a final reservation. That these reservations and the records thereof are claimed as being effectuated on computer elements does not somehow avoid this abstract concept (see, e.g., the seminal Alice and the content of MPEP 2106.04(a)(2)(II)).
Further on the topic of Prong One, Examiner notes that these arguments address the abstract category of certain methods of organizing activity, but entirely ignore the also-recited abstract categories of mental processes and mathematical concepts. As such, even if Applicant’s arguments here were persuasive (which, to be clear, they are not as discussed above), the claims would still recite abstract ideas under the Prong One analysis.
Regarding Step 2A, Prong Two, Applicant argues that the claims embody an improvement to a technology, specifically that “claim 44 is directed to a specific improvement in computerized reservation platforms, particularly in the way such systems enforce resource availability consistency and prevent conflicting allocations across multiple users.” Applicant attempts to support this argument by asserting that “the claim recites specific technological mechanisms that go beyond generic data processing. In particular, the claim requires generating a temporary reservation that prevents another user from completing a conflicting reservation. This is a specific solution to a concurrency problem in distributed reservation systems. It is not merely recording a reservation, but controlling system state to enforce exclusivity during transaction processing. The claim further requires updating inventory to indicate that the selected resource is unavailable for the requested time. This imposes a time- based constraint on system state, ensuring that overlapping reservations cannot occur, and resource availability remains consistent across the platform. This is a technical control of system data structures, not an abstract business rule.” Examiner disagrees, noting that this argument merely cloaks broader, abstract concepts in technical jargon in similar manner as several previously advanced and refuted assertions of improvements to technology (see previous Office Actions).
The claims do not embody such an improvement to a technology. As has now been pointed out in multiple previous Office Actions, MPEP 2106.05(a) specifies that such an improvement to a technology is a “technological solution to a technological problem,” and further that “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology.” In these arguments, Applicant again merely describes an improvement to an abstract idea itself, said abstract improvement happening to have been claimed as being effectuated on computers. As explained above regarding Prong One, the elements argued by Applicant here are not additional elements, but rather abstract ideas which are claimed at a high level as being effectuated by generic computer elements. The claims do not set forth any particular “specific technological mechanisms” as argued, but rather claim a sequence of abstract steps performed on computer elements. There is nothing inherently technological about making a temporary reservation of a resource and recording that reservation (e.g., in a ledger) such that other customers are prevented from reserving that same resource during the reservation period. Similarly, it is equally as clear that the presented solution is abstract in nature, as the making and recording/communicating of such temporary reservations would also achieve the same results if performed manually: as with any reservation of a resource, said resource is held as unavailable for use by any other customer during the reserving customer’s reservation period. Indeed, even ignoring the above, it is particularly telling that this functionality is not inventive as it is solely disclosed in a single throw-away sentence in Paragraph 0069 and is never mentioned again, to say nothing of the existence of such temporary reservations in the reservation arts long-prior to Applicant’s effective filing date.
Claiming this process as occurring via computer elements does not somehow transform this concept into a technological one, nor the problem addressed thereby (as articulated by Applicant, “the problem of conflicting reservations across concurrent users”) into a technological problem. Merely couching this broader abstract problem as occurring in “distributed reservation systems” does not limit the problem or solution to such systems. Indeed, it is abundantly clear that this is not a technological problem, as this same problem exists regardless of whether the reservation process occurs via computer elements as claimed or is performed manually (e.g., without the creation and recording of a temporary reservation during the reservation process, this argued conflict could arise in the same way for customers making reservations at different offices, or even the same office at different service desks). Designating such a resource as reserved as claimed does not capture change or control of a “system state” as argued, nor does the original disclosure appear to support this idea at all, rendering this no more than unsupported attorney argument, which cannot take the place of evidence in the record (see, e.g., Cf In re Geisler, 116 F.3d 1465, 1470 (Fed. Cir. 1997)). Even if such support were hypothetically present, this would constitute no more than mere automation of a manual process, which has long been judicially recognized as insufficient to embody an improvement to a technology (see, e.g., Credit Acceptance Corp. v. Westlake Services, 859 F.3d 1044, 1055, 123 USPQ2d 1100, 1108-09 (Fed. Cir. 2017) and LendingTree, LLC v. Zillow, Inc., 656 Fed. App'x 991, 996-97 (Fed. Cir. 2016)).
Regarding Applicant’s additional argument that “claim 44 determines a provider from among providers having the resource in inventory and coordinates allocation accordingly. This reflects automated system-level coordination across multiple entities, not a mental process,” Examiner disagrees with this as well. Indeed, this essentially repeats an argument previously advanced and refuted multiple times thus far in a far more vague manner than as previously presented, and the content of the previous Office Actions remains fully sufficient to refute the present reiteration of this argument. See the Response to Applicant’s Arguments section of both the Final Rejection of 6/24/2026 and the Non-Final Rejection of 1/13/2026 for more information on this topic.
Regarding the Applicant’s statement that “[t]he Examiner focuses on ‘checking availability’ and ‘data formatting’” within these Prong Two arguments, Examiner notes that Applicant’s reference to “data formatting” is entirely irrelevant given the removal of this functionality in the present claim amendments (in view of the previous 112(a) rejection thereof), and while “checking availability” does not constitute the entirety of Claim 44 functionality (nor has it ever done so), its presence in Claim 44 remains just as abstract as presently drafted.
Regarding Step 2B, Applicant argues that the claims recite an inventive concept, particularly asserting that the combination of the claim elements of “generating a temporary reservation prior to final allocation, updating inventory to enforce time-based exclusivity, and preventing competing reservation completion by other users” are not well-understood, routine, and conventional. Examiner disagrees, noting that Applicant misapprehends the “well-understood, routine, and conventional” consideration of Step 2B, including how and to what it applies, in similar manner as explained to Applicant in the Final Rejection of 6/24/2026. As explained above, each of these argued functions recite abstract ideas, and do not constitute additional elements (rather, in relation to these steps, merely the computer elements claimed as performing these steps constitute additional elements). As per at least MPEP 2106.05, 2106.05(d), and the most recent PEG Update, the well-understood, routine, and conventional consideration of Step 2B applies solely to additional elements, and further to those additional elements sub-categorized as insignificant extra-solution activity. Even ignoring that no element as presently claimed as found to recite insignificant extra-solution activity, it is entirely irrelevant whether any recited abstract ideas or the combination thereof are well-understood, routine, and conventional.
Claim Rejections – 35 USC § 103
Applicant’s arguments regarding the 103 analysis have been considered and are unpersuasive.
Applicant’s art-based arguments are entirely based on newly presented claim language, and as such need not be addressed here. Further, these arguments are moot in view of the updated 103 rejections below. Additionally, Applicant’s particular assertion that the primary Patel reference does not teach or suggest the feature of “(1) display of resources available to a particular user-defined location” is untrue, and Applicant is encouraged to take greater care in reviewing references before making such inaccurate assertions. See updated 103 rejections below for more information.
Claim Objections
Claim 44 is objected to because of the following informalities:
“identifying a plurality of third party service providers based on an identified location associated with the request and queries directed to…” should read “identifying a plurality of third party service providers based on an identified location associated with the request and initiating queries directed to…” or similar;
“…the resource is available from among the one or more third party resource providers” should read “the resource is available from among the plurality of third party resource providers” to maintain proper antecedent basis;
“determining, by the platform, a resource provider from a set of resource providers that have the selected resource in inventory” should read “determining, by the platform, a resource provider from a set of resource providers that has the selected resource in inventory;”
“…unavailable for the requested time. receiving, from the platform, an indication…” should read “…unavailable for the requested time; receiving, from the platform, an indication…”
Appropriate correction is required.
Claim Rejections – 35 USC § 112
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 44-49 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 44 contains the following limitation: “determining, by the platform, a resource provider from a set of resource providers that have the selected resource in inventory.” This limitation, in the context of the remainder of Claim 44, is indefinite for multiple reasons. Firstly, the term “the selected resource” lacks antecedent basis, as the only selection preceding this limitation as claimed is a “user selection of a location at which delivery of a resource is to be received.” To be clear, Examiner does interpret this “user selection of a location at which delivery of a resource is to be received” as the selection of a reservable resource on a map interface as described in Paragraphs 0067, 0078, and 0100, as there is no other supported user selection of anything via a map interface (e.g., Paragraph 0067 states that the user request may comprise a user location, but there is no support for that location having been provided via a selection on a map interface) anywhere in the original disclosure; nonetheless, this is a flaw in claim drafting. Additionally, it is unclear as drafted whether this limitation is describing the same step or different step from either the preceding limitation “receiving, via the API, the set of available resources determined by the platform based on responses to the queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available from among the one or more third party resource providers, the set of available resources being determined at a time of processing of the request and corresponding to resources available at the requested time and meeting the resource criteria defined in the request” or the subsequent limitation “receiving, from the platform, an indication that the resource has been allocated, at a resource provider, to a user account associated with the user” within the claimed method. So far as Examiner can see from the original disclosure, there is nothing to indicate that the invention may comprise multiple instances of availability determination/such a check for availability of a specifically selected resource subsequent to said selection, merely the call-and-response to the corresponding third party provider to confirm said provider has reserved the selected resource (ie: as in the second of the above-listed other limitations of Claim 44) which is not equivalent to the claimed determination that a corresponding resource provider has the selected resource in inventory. As such, both to clarify the above-discussed indefiniteness issues and to avoid a 112(a) new matter rejection, for the purposes of this examination the limitation “determining, by the platform, a resource provider from a set of resource providers that have the selected resource in inventory” will be interpreted as a superfluous reiteration of one of the above-listed other limitations of Claim 44, and thus this limitation is not given patentable weight. While this interpretation avoids the necessity for a 112(a) new matter rejection regarding lack of support for multiple instances of this functionality within a single method instance, Applicant is considered on notice of this issue. Claims 45-49 are rejected due to their dependence upon Claim 44.
Claim 44 contains multiple instances of the limitation “a resource provider,” and it is unclear as drafted whether the subsequent instance of this term is intended to relate back to the former instance or to indicate a separate resource provider. Similarly, Claim 44 contains both “an associated set of resource providers” and “a set of resource providers,” and it is unclear as drafted whether these terms indicate the same or different sets of resource providers. The interpretation of the limitation “determining, by the platform, a resource provider from a set of resource providers that have the selected resource in inventory” in the rejection immediately above, wherein this limitation is interpreted as a superfluous reiteration of a preceding limitation (and thus not giving this limitation patentable weight), is sufficient to avoid these issues without further modification. Claims 45-49 are rejected due to their dependence upon Claim 44.
Claim 44 contains the following limitations: “receiving, via a map user interface, user selection of a location at which delivery of a resource is to be received,” “generating a user interface comprising one or more selectable elements corresponding to one or more resources from the set of available resources for selection by the user of the computing device, the one or more selectable elements being available to be provided from the resource provider at the location,” and “receiving, via the user interface, user selection of a selectable element from among the one or more selectable elements that corresponds to a resource from the one or more resources.” It is unclear as drafted whether these limitations are intended to recite multiple iterations of presentation of a set of resources available for reservation to a user via an interface, and receipt of selection of one such resource available for reservation from a user via said interface, or whether these limitations are intended to recite the same functions at differing levels of detail. As a sub-issue of this, it is unclear as drafted whether “a map interface” and “a/the user interface” are intended to indicate the same or different interfaces. So far as Examiner can see from the original disclosure, there is nothing to indicate that the invention may comprise multiple instances of such presentations and selections occurring within a singular method of resource reservation for a user. As such, both to clarify the above-discussed indefiniteness issues and to avoid a 112(a) new matter rejection, for the purposes of this examination the limitation “receiving, via a map user interface, user selection of a location at which delivery of a resource is to be received” is interpreted as claiming the same functions set forth in the limitations “generating a user interface comprising one or more selectable elements corresponding to one or more resources from the set of available resources for selection by the user of the computing device, the one or more selectable elements being available to be provided from the resource provider at the location,” and “receiving, via the user interface, user selection of a selectable element from among the one or more selectable elements that corresponds to a resource from the one or more resources,” providing additional details in relation thereto (e.g., specifying that “a/the user interface” of these limitations is a “map interface”). While this interpretation avoids the necessity for a 112(a) new matter rejection regarding lack of support for multiple instances of this functionality within a single method instance, Applicant is considered on notice of this issue. Claims 45-49 are rejected due to their dependence upon Claim 44.
Claim 44 contains the following language: “the one or more selectable elements being available to be provided from the resource provider at the location.” It is unclear as drafted how the one or more selectable elements may simultaneously be comprised on a user interface provided/generated by the platform and available to be provided from the resource provider from the resource provider at the location.” It is additionally unclear whether “the location” in this language is intended to relate back to “an identified location associated with the request” or “a location at which delivery of a resource is to be received.” If the latter, given the interpretation of the “receiving, via a map user interface, …,” “generating a user interface comprising…,” and “receiving, via the user interface, user selection of…” limitations above, this causes an additional indefiniteness issue of circular logic, as it references a location which is not selected until after generation of the user interface and selectable elements thereof. For the purposes of this examination, this language will be interpreted as “each of the one or more resources from the set of available resources available to be provided from a respective location of a respective third party service provider.” Claims 45-49 are rejected due to their dependence upon Claim 44.
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 44-49 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Regarding Claim 49, the limitations of requesting a set of available resources from the platform, wherein requesting the set of available resources includes transmitting a request that includes a requested time and a set of resource criteria; identifying a plurality of third party service providers based on an identified location associated with the request and queries directed to a plurality of third party service providers; receiving, via the API, the set of available resources determined by the platform based on responses to the queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available from among the one or more third party resource providers, the set of available resources being determined at a time of processing of the request and corresponding to resources available at the requested time and meeting the resource criteria defined in the request; aggregating availability data returned from the plurality of third party resource providers to generate the set of available resources; receiving user selection of a location at which delivery of a resource is to be received; determining a resource provider from a set of resource providers that have the selected resource in inventory; generating a list comprising one or more resources from the set of available resources for selection by the user, each of the one or more resources from the set of available resources available to be provided from a respective location of a respective third party service provider; receiving user selection of a selectable element from among the one or more selectable elements that corresponds to a resource from the one or more resources; providing a resource request indicating the selected resource as a requested resource from the platform; wherein providing the resource request causes the platform to generate a temporary reservation for the selected resource, thereby ensuring another user does not complete a reservation process for the selected resource before the user; updating an inventory associated with the platform to indicate the selected resource is unavailable for the requested time; receiving, from the platform, an indication that the resource has been allocated, at a resource provider, to a user account associated with the user; and providing a graphical indication that the selected resource has been successfully allocated, as drafted, are processes that, under their broadest reasonable interpretations, cover certain methods of organizing human activity. For example, these limitations fall at least within the enumerated categories of commercial or legal interactions and/or managing personal behavior or relationships or interactions between people (see MPEP 2106.04(a)(2)(II)).
Additionally, the limitations of requesting a set of available resources from the platform, wherein requesting the set of available resources includes transmitting a request that includes a requested time and a set of resource criteria; identifying a plurality of third party service providers based on an identified location associated with the request and queries directed to a plurality of third party service providers; receiving, via the API, the set of available resources determined by the platform based on responses to the queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available from among the one or more third party resource providers, the set of available resources being determined at a time of processing of the request and corresponding to resources available at the requested time and meeting the resource criteria defined in the request; aggregating availability data returned from the plurality of third party resource providers to generate the set of available resources; receiving user selection of a location at which delivery of a resource is to be received; determining a resource provider from a set of resource providers that have the selected resource in inventory; generating a list comprising one or more resources from the set of available resources for selection by the user, each of the one or more resources from the set of available resources available to be provided from a respective location of a respective third party service provider; receiving user selection of a selectable element from among the one or more selectable elements that corresponds to a resource from the one or more resources; providing a resource request indicating the selected resource as a requested resource from the platform; wherein providing the resource request causes the platform to generate a temporary reservation for the selected resource, thereby ensuring another user does not complete a reservation process for the selected resource before the user; updating an inventory associated with the platform to indicate the selected resource is unavailable for the requested time; receiving, from the platform, an indication that the resource has been allocated, at a resource provider, to a user account associated with the user; and providing a graphical indication that the selected resource has been successfully allocated, as drafted, are processes that, under their broadest reasonable interpretations, cover mental processes. For example, these limitations recite activity comprising observations, evaluations, judgments, and opinions (see MPEP 2106.04(a)(2)(III)).
Additionally, the limitation of identifying a plurality of third party service providers based on an identified location associated with the request and queries directed to a plurality of third party service providers, as drafted, is a process that, under its broadest reasonable interpretation, covers mathematical concepts. For example, these limitations recite mathematical relationships and/or calculations (see MPEP 2106.04(a)(2)(I)).
If a claim limitation, under its broadest reasonable interpretation, covers fundamental economic principles or practices, commercial or legal interactions, managing personal behavior or relationships, or managing interactions between people, it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind or with the aid of pen and paper but for recitation of generic computer components, it falls within the “Mental Processes” grouping of abstract ideas. If a claim limitation, under its broadest reasonable interpretation, covers mathematical relationships, mathematical formulae or equations, or mathematical calculations, it falls within the “Mathematical Concepts” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a computing device; an application programming interface (API); a platform; a plurality of third party resource provider computing systems; a map interface; and generating a user interface comprising one or more selectable elements. These, in the context of the claim as a whole, amount to no more than mere instructions to apply a judicial exception (see MPEP 2106.05(f)). Accordingly, these additional elements do not integrate the abstract ideas into a practical application because they do not, individually or in combination, impose any meaningful limits on practicing the abstract ideas. The claim is therefore directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the judicial exception into a practical application, the additional elements amount to no more than mere instructions to apply a judicial exception for the same reasons as discussed above in relation to integration into a practical application. These cannot provide an inventive concept. Therefore, when considering the additional elements alone and in combination, there is no inventive concept in the claim, and thus the claim is not patent eligible.
Claims 45-49, describing various additional limitations to the method of Claim 44, amount to substantially the same unintegrated abstract idea as Claim 44 (upon which these claims depend, directly or indirectly) and are rejected for substantially the same reasons.
Claim 45 discloses receiving, from the platform, an allocation update associated with the allocated resource, the allocation update being generated in response to a state change received from the resource provider (an abstract idea in the form of a certain method of organizing human activity and a mental process); and providing, via the user interface, an indication of the allocation update (an abstract idea in the form of a certain method of organizing human activity and a mental process), which do not integrate the claim into a practical application.
Claim 46 discloses wherein the indication comprises a map indicating a geographic location of a computing device of a second user associated with the resource provider (further defining the abstract idea already set forth in Claim 45), which does not integrate the claim into a practical application.
Claim 47 discloses the received user selection comprises a selection of a resource request type (further defining the abstract idea already set forth in Claim 44); and the resource request to the platform comprises an indication of the selected resource request type (further defining the abstract idea already set forth in Claim 44), which do not integrate the claim into a practical application.
Claim 48 discloses wherein requesting the set of available resources from the platform further comprises providing an indication of a geographic location of the computing device (further defining the abstract idea already set forth in Claim 44), which does not integrate the claim into a practical application.
Claim 49 discloses wherein the user interface comprising the one or more resources further comprises an indication of a distance between the geographic location of the computing device and a resource provider associated with each resource of the one or more resources (further defining the abstract idea already set forth in Claim 44), which does not integrate the claim into a practical application.
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.
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 44 and 47 are rejected under 35 U.S.C. 103 as being unpatentable over Patel et al (PGPub 20180330283) (hereafter, “Patel”) in view of Eklund (PGPub 20170270556) (hereafter, “Eklund”) and Kalik et al (PGPub 20090204600) (hereafter, “Kalik”).
Regarding Claim 44, Patel discloses:
requesting, by a computing device of a user and via an application programming interface (API) of the platform, a set of available resources from the platform, wherein requesting the set of available resources includes transmitting a request that includes a requested time and a set of resource criteria (¶ 0035, 0042, 0046-0048, 0052, 0061, 0068; Figs. 1-2; travel service computer system allowing for the search and reservation of lodging, flights, vehicle rentals, etc.; the process starts when the travel search service system receives from the client device user input indicating the search criteria; stay criteria may include without limitation one or more of: a location (e.g., city, state, region, district, zip code, neighborhood), check-in/check-out dates, a price range (e.g., maximum and/or minimum prices), star ratings (e.g., three star, four star, etc.), lodging types (e.g., hotel, motel, bed-and-breakfast), lodging amenities (e.g., pool, exercise room, free breakfast); room types (e.g., single, suite), room amenities (e.g., bed type, hot tub, view), activities (e.g., golf, gambling, skiing); proximity to attractions (e.g., beaches, parks, mountains), and other lodging-related criteria; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received, and book a selected option via one or more booking APIs; search APIs;);
identifying a plurality of third party service providers based on an identified location associated with the request and queries directed to a plurality of third party resource provider computing systems corresponding to the plurality of third party service providers (¶ 0041-0042, 0045-0048, 0052, 0061, 0072; Figs. 1-2; the travel search service system then provides the client device the search results; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received (e.g., location, check-in/check-out dates), and book a selected option via one or more booking APIs; the search criteria for a corresponding search might thus include “Chicago” as a location, “3/13” as the check-in date, and “3/20” as the check-out date; the search results for this example search query might include one stay option for the “Drake Hotel” at $150 per night and another stay option at the “W Hotel” for $175 per night; lodging search criteria includes stay criteria to book lodging reservations such as, for example, location (e.g., city, state); the travel service computer system is a networked system by which a user may obtain, among other travel-related information, lodging search results that meet a user's specified lodging search criteria; the data sources from which service options are queried and/or booked include OTA (Online Travel Agencies) systems (e.g., Orbitz, Travelocity) and individual lodging systems (e.g., an individual hotel website), both of which represent third party resource providers; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources, e.g., the OTA systems; the mixture query instructions may likewise be configured to format the search requests to the information sources according to the specifications of the information sources and based on the user-submitted search criteria in the sub-queries; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria in order to determine whether any rate savings result from a split stay as compared to a full stay; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources);
receiving, via the API, the set of available resources determined by the platform based on responses to the queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available from among the one or more third party resource providers, the set of available resources being determined at a time of processing of the request and corresponding to resources available at the requested time and meeting the resource criteria defined in the request (¶ 0045-0047, 0052, 0061; Figs. 1-2; the travel search service system then provides the client device the search results; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received (e.g., check-in/check-out dates), and book a selected option via one or more booking APIs; the data sources from which service options are queried and/or booked include OTA (Online Travel Agencies) systems (e.g., Orbitz, Travelocity) and individual lodging systems (e.g., an individual hotel website), both of which represent third party resource providers; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources, e.g., the OTA systems; the mixture query instructions may likewise be configured to format the search requests to the information sources according to the specifications of the information sources and based on the user-submitted search criteria in the sub-queries; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria in order to determine whether any rate savings result from a split stay as compared to a full stay; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources);
aggregating availability data returned from the plurality of third party resource providers to generate the set of available resources (¶ 0041-0042, 0045-0048, 0052-0053, 0061-0065, 0072; Figs. 1-2, 3A-3C; the travel search service system then provides the client device the search results; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received (e.g., location, check-in/check-out dates), and book a selected option via one or more booking APIs; the search criteria for a corresponding search might thus include “Chicago” as a location, “3/13” as the check-in date, and “3/20” as the check-out date; the search results for this example search query might include one stay option for the “Drake Hotel” at $150 per night and another stay option at the “W Hotel” for $175 per night; lodging search criteria includes stay criteria to book lodging reservations such as, for example, location (e.g., city, state); the travel service computer system is a networked system by which a user may obtain, among other travel-related information, lodging search results that meet a user's specified lodging search criteria; the data sources from which service options are queried and/or booked include OTA (Online Travel Agencies) systems (e.g., Orbitz, Travelocity) and individual lodging systems (e.g., an individual hotel website), both of which represent third party resource providers; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources, e.g., the OTA systems; the mixture query instructions may likewise be configured to format the search requests to the information sources according to the specifications of the information sources and based on the user-submitted search criteria in the sub-queries; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria in order to determine whether any rate savings result from a split stay as compared to a full stay; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources; generate one or more web pages of search results returned to the client device and displayed in a web browser; an exploration tool configured to search for and book options, utilizing at least one type of user interface; each stay option includes control elements used to book and/or view the details for the respective stay options (e.g., as illustrated in Figs. 3A-3C, the "View Deal" and "Book" buttons));
determining, by the platform, a resource provider from a set of resource providers that have the selected resource in inventory (¶ 0045-0047, 0052, 0061; Figs. 1-2; the travel search service system then provides the client device the search results; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received (e.g., check-in/check-out dates), and book a selected option via one or more booking APIs; the data sources from which service options are queried and/or booked include OTA (Online Travel Agencies) systems (e.g., Orbitz, Travelocity) and individual lodging systems (e.g., an individual hotel website), both of which represent third party resource providers; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources, e.g., the OTA systems; the mixture query instructions may likewise be configured to format the search requests to the information sources according to the specifications of the information sources and based on the user-submitted search criteria in the sub-queries; various information sources may provide search APIs that define the format and content of search requests that can be submitted at their respective systems; the mixture query instructions may thus be configured to utilize those search APIs when executing sub-queries at those information sources; the mixture query instructions may also be configured to execute a search query based on the user's original search criteria in order to determine whether any rate savings result from a split stay as compared to a full stay; the mixture query instructions may likewise execute the search query based on the user's original search criteria at the “live” pricing and availability database and/or one or more of the information sources);
generating a user interface comprising one or more selectable elements corresponding to one or more resources from the set of available resources for selection by the user of the computing device, the one or more selectable elements being available to be provided from the resource provider at the location (¶ 0053, 0061-0065; Figs. 3A-3C; generate one or more web pages of search results returned to the client device and displayed in a web browser; an exploration tool configured to search for and book options, utilizing at least one type of user interface; each stay option includes control elements used to book and/or view the details for the respective stay options (e.g., as illustrated in Figs. 3A-3C, the "View Deal" and "Book" buttons));
receiving, via the user interface, user selection of a selectable element from among the one or more selectable elements that corresponds to a resource from the one or more resources (¶ 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; ; each stay option includes control elements used to book and/or view the details for the respective stay options (e.g., as illustrated in Figs. 3A-3C, the "View Deal" and "Book" buttons));
providing, via the API, a resource request indicating the selected resource as a requested resource from the platform (¶ 0046-0047, 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received, and book a selected option via one or more booking APIs);
updating an inventory associated with the platform to indicate the selected resource is unavailable for the requested time (¶ 0021, 0046, 0058, 0061, 0081; Figs 1-2, 7; the travel search service system includes, e.g., a “live” pricing and availability database; the pricing and availability information stored in the “live” pricing and availability database may be accurate to within such a small margin of error (e.g., 3-4% in some cases) that performing the user's search query at the “live” pricing and availability database would be highly likely to provide the same results as if the user's search query were performed at the information sources themselves; the travel search service system may keep a record of each split stay it books on behalf of a user; the travel search service system then books each leg of the selected split stay on behalf of the user; the function of a reservation as customarily if not universally understood is to allocate a resource to a user for a set period such that the resource cannot be used or reserved by others during that period);
receiving, from the platform, an indication that the resource has been allocated, at a resource provider, to a user account associated with the user (¶ 0003, 0016, 0034-0035, 0042, 0044, 0061, 0065; Figs. 1-3A; the travel search service system then books each of the options (from the relevant provider(s)) selected for reservation on behalf of the user; having successfully booked the selected option on behalf of the user, the exploration tool may provide a confirmation message (e.g., displayed on-screen and/or provided via email)); and
providing, via the user interface, a graphical indication that the selected resource has been successfully allocated (¶ 0003, 0016, 0034-0035, 0042, 0044, 0061, 0065; Figs. 1-3A; the travel search service system then books each of the options (from the relevant provider(s)) selected for reservation on behalf of the user; having successfully booked the selected option on behalf of the user, the exploration tool may provide a confirmation message (e.g., displayed on-screen and/or provided via email)).
Patel additionally discloses receiving, via a user interface, user selection of a location at which delivery of a resource is to be received (¶ 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; ; each stay option includes control elements used to book and/or view the details for the respective stay options (e.g., as illustrated in Figs. 3A-3C, the "View Deal" and "Book" buttons)). Patel does not explicitly disclose but Eklund does disclose wherein the user interface is a map user interface (¶ 0152; Fig. 12B; a user may send a request for a hotel search via his/her UE by clicking “find a hotel” tab; then, the channel manager platform may search amongst the participating hotels based in proximity information, pricing information, availability information, and so on; subsequently, the user may be presented with a list on a map in his/her UE).
Patel does not explicitly disclose but Kalik does disclose causing the platform to generate a temporary reservation for the selected resource, thereby ensuring another user does not complete a reservation process for the selected resource before the user (¶ 0009, 0031-0032, 0071, 0073; Fig. 2; making one or more tentative reservation(s); the requester may choose to accept or reject the recommendation; if accepted, the corresponding tentative reservation is confirmed; tentative reservations may be required in cases such as resources provided through ticketing services; in such cases, the tickets available will otherwise be offered to other requesters unless the system agrees to hold them temporarily as a reservation, to permit an answer to be returned from the requestor accepting or rejecting acquisition of the proposed resource). Patel additionally discloses wherein the reservation is caused by providing the resource request (¶ 0046-0047, 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received, and book a selected option via one or more booking APIs).
It further would have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to include the resource reservation search and display techniques of Eklund with the resource reservation system of Patel and Bellotti because the combination merely applies a known technique to a known device/method/product ready for improvement to yield predictable results (see KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 415-421 (2007) and MPEP 2143). The known techniques of Eklund are applicable to the base device (Patel, Rosner, and Bellotti), the technical ability existed to improve the base device in the same way, and the results of the combination are predictable because the function of each piece (as well as the problems in the art which they address) are unchanged when combined. One of ordinary skill in the art would further have been motivated to include the temporary resource reservation functionality of Kalik with the resource reservation system of Patel to prevent the resource from being offered to other requesters (see at least Paragraph 0071 of Kalik).
Regarding Claim 47, Patel in view of Eklund and Kalik discloses the limitations of Claim 44. Patel additionally discloses:
the received user selection comprises a selection of a resource request type (¶ 0007, 0048, 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; the provided user interface of one or more resources may comprise one or more indications of a resource type in relation to each listed resource (e.g., room type, rating, stars, as in Figs. 3A-3C); selection of a resource by user and subsequent transmission of said selection by extension indicates a selection of the associated resource type(s)); and
the resource request to the platform comprises an indication of the selected resource request type (¶ 0046-0048, 0061-0065; Figs. 1, 3A-3C; the travel search service system then receives user input indicating an option selected by the user to book; the user input received may include user information, payment information, and other information used to complete a booking; the travel search service system is configured to receive stay criteria from the user, perform queries according to the stay criteria received, and book a selected option via one or more booking APIs; the provided user interface of one or more resources may comprise one or more indications of a resource type in relation to each listed resource (e.g., room type, rating, stars, as in Figs. 3A-3C); selection of a resource by user and subsequent transmission of said selection by extension indicates a selection of the associated resource type(s)).
Claims 45-46 and 48-49 are rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Eklund, Kalik, and Bellotti et al (PGPub 20180238694) (hereafter, “Bellotti”).
Regarding Claim 45, Patel in view of Eklund and Kalik discloses the limitations of Claim 44. Patel does not explicitly disclose but Bellotti does disclose:
receiving, from the platform, an allocation update associated with the allocated resource, the allocation update being generated in response to a state change received from the resource provider (¶ 0007-0008, 0039; the system can also return, and device can also receive and display: the current location of the driver, and original planned driver route to meeting point) and
providing, via the user interface, an indication of the allocation update (¶ 0007-0008, 0035-0036, 0042; Fig. 1A; device 108 can include a pedestrian display, which is a map that identifies: the passenger, driver and/or vehicle, etc.; the system can dynamically update the target location and provide to both the passenger and the vehicle updated routes to the updated meeting point, in response to such an "en-route action" by either the passenger or the vehicle; displaying a current location of the passenger as the passenger travels to the target location; and displaying a current location of the vehicle as the vehicle travels to the target location).
The rationale to combine the Patel, Eklund, and Kalik references remains the same as for Claim 44. It would further have been obvious to one of ordinary skill in the art before the filing date of the claimed invention to include the reservation display and update techniques of Bellotti with the resource reservation system of Patel because the combination merely applies a known technique to a known device/method/product ready for improvement to yield predictable results (see KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 415-421 (2007) and MPEP 2143). The known techniques of Bellotti are applicable to the base device (Patel), the technical ability existed to improve the base device in the same way, and the results of the combination are predictable because the function of each piece (as well as the problems in the art which they address) are unchanged when combined.
Regarding Claim 46, Patel in view of Eklund, Kalik, and Bellotti discloses the limitations of Claim 45. Patel does not explicitly disclose but Bellotti does disclose wherein the indication comprises a map indicating a geographic location of a computing device of a second user associated with the resource provider (¶ 0007-0008, 0035-0036, 0042; Fig. 1A; device 108 can include a pedestrian display, which is a map that identifies: the passenger, driver and/or vehicle, etc.; the system can dynamically update the target location and provide to both the passenger and the vehicle updated routes to the updated meeting point, in response to such an "en-route action" by either the passenger or the vehicle; displaying a current location of the passenger as the passenger travels to the target location; and displaying a current location of the vehicle as the vehicle travels to the target location).
The rationale to combine remains the same as for Claim 45.
Regarding Claim 48, Patel in view of Eklund and Kalik discloses the limitations of Claim 44. Patel does not explicitly disclose but Bellotti does disclose wherein requesting the set of available resources from the platform further comprises providing an indication of a geographic location of the computing device (Abstract; ¶ 0002, 0004, 0023; the system generates, by a first mobile computing device associated with a passenger at a first location, a request for transportation; a (would be) passenger can request a ride by providing the passenger's location).
The rationale to combine remains the same as for Claim 45.
Regarding Claim 49, Patel in view of Eklund, Kalik, and Bellotti discloses the limitations of Claim 48. Patel does not explicitly disclose but Eklund does disclose wherein the user interface comprising the one or more resources further comprises an indication of a distance between the geographic location of the computing device and a resource provider associated with each resource of the one or more resources (¶ 0152; Fig. 12B; the channel manager platform may search amongst the participating hotels based on proximity information, etc.; subsequently, the user may be presented with a list on a map in his/her UE).
The rationale to combine remains the same as for Claim 45.
Discussion of Prior Art Cited but Not Applied
For additional information on the state of the art regarding the claims of the present application, please see the following documents not applied in this Office Action (all of which are prior art to the present application):
PGPub 20170278126 – “System and Method for Utilizing Virtual and Real Currencies for Processing Cruise and Cruise-Related Transactions,” Rowley et al, disclosing a system for tracking and using credits to make purchases
PGPub 20050043992 – “Point Pooling Loyalty System and Method,” Cohagan et al, disclosing a system for purchasing and using credits to make purchases
PGPub 20150032768 – “Managing Item Queries,” Miller et al, disclosing a system for the searching and reservation of various resources, each resource offered from a variety of providers
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 MARK C CLARE whose telephone number is (571)272-8748. The examiner can normally be reached Monday-Friday 6:30am-2:30pm EST.
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, Jeffrey Zimmerman can be reached at (571) 272-4602. 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.
/MARK C CLARE/Examiner, Art Unit 3628
/MICHAEL P HARRINGTON/Primary Examiner, Art Unit 3628
Prosecution Insights