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 RCE filed on 11/24/2025.
Claims 44-45 have been amended and are hereby entered.
Claims 37-56 are currently pending, with 44-49 having been examined and 37-43 and 50-56 having been withdrawn without traverse.
Request for Continued Examination
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 11/24/2025 has been entered.
Response to Applicant’s Arguments
Claim Rejections – 35 USC § 112
While there were no previous 112-based rejections in the most recent Office Action (ie: the Final Rejection of 6/24/2025) and thus no arguments are presented based on 112 standards in the present Remarks, Examiner finds it pertinent to address this topic here in view of content of the previous rejection’s Response to Applicant’s Arguments section and its relevance to the claims as presently amended. Particularly, Examiner pointed to an issue in the Final Rejection of 6/24/2025, said issue only being a potential issue at the time as it related to features (specifically, real-time API-based resource availability queries made in response to the request) which Applicant then-argued in the Remarks of 6/03/2025 but did not properly embody these features in the claims at that time.
This was a then-theoretical issue of new matter, in that what was actually then-claimed was properly supported by the original disclosure but the features being argued by Applicant were not. Said Final Rejection of 6/24/2025 explained the shortcomings of the original disclosure in arguing these then-unembodied features, distinguishing from the content of the original disclosure and ending with the following: “As best as Examiner can discern from the combination of the present arguments and the original disclosure, Applicant’s argument misapprehends the content of the original disclosure and/or reads far more into the original disclosure than is actually there. As such, it is somewhat fortunate that the present claim drafting fails to capture this argued functionality, as this avoids the necessity for 112(a) new matter rejections at present.”
Despite this, Applicant has chosen to amend the claims presently to embody these unsupported features, and further makes no attempt to refute the previously pointed out lack of support for these features nor assert that these features are supported at all. This results in one of the 112(a) new matter rejections below. Other 112(a) new matter rejections are also given below in light of similar lack of support in the original disclosure for separate newly-claimed features. Given the lack of full and proper support in the original disclosure for any of the present amendments, Applicant may wish to review at least 35 USC 132 and MPEP 608.04, 2163.01, 2163.06, etc. Note further that this is not something that can be cured by amending this unsupported subject matter into the specification, drawings, etc., as such amendments of new matter require objection and removal (see, e.g., MPEP 608.01(q), 608.04, 2163.06, etc.).
Claim Rejections – 35 USC § 101
Applicant’s arguments regarding the 101 analysis have been considered and are unpersuasive.
As a preliminary matter, Applicant presents 101 arguments under two separate headings (ie: “1. The claims as presented are not abstract,” and 1. [sic] The claims as presented integrate any judicial exception into a practical application”); however, while the first of these headings contains a single conclusory argument which appear targeted to Step 2A, Prong One standards, the majority of the content under both headings are actually targeted to the same standard: the “directed to” inquiry of Step 2A, Prong Two (ie: the determination of what a claim is “directed to” and the determination of whether the claims are integrated into a practical application are not two separate inquiries, but instead are merely two different descriptions of the same step), particularly assertions of technological improvements (see, e.g., MPEP 2106.04(d), 2106.05(a)). For clarity, Examiner does not address these arguments as organized by Applicant, but instead attempts to parse these arguments and address them in relation to the particular 101 subject matter eligibility standard to which they are particularly related.
Regarding Step 2A, Prong One, Applicant references “now explicitly requir[ed] real-time initiation of availability queries to multiple third-party provider systems at the time of request processing,” “normalization of heterogeneous third-party availability data into a unified structure,” and “coordinat[ing] availability, allocation, and provider-side updates via structured APIs including callback APIs/webhooks,” making the conclusory assertion that “[t]hese limitations describe specific computer system architectures and data processing techniques—not abstract business methods that could be performed mentally or with pen and paper.” Examiner disagrees, finding that Applicant appears to misapprehend and misapply Step 2A, Prong One standards.
Regarding the first two of these asserted features, these were already addressed in the previous Office Action, both in terms of Step 2A, Prong One and Prong Two standards, despite them being argued but not properly claimed at the time. The explanations provided in said previous Office Action are equally correct at present, and even to the limited extent Applicant attempts to refute these previously provided explanations, these attempts are unsuccessful (addressed as applicable below). See the Final Rejection of 6/24/2025 for more information.
Ignoring that each of these features as presently claimed lacks proper support in the original disclosure and must be removed to overcome the 112(a) rejections below, Applicant misapprehends the distinction between abstract ideas and additional elements. It has long been established, including in the seminal Alice which Applicant invokes later in these remarks, merely claiming a step or process as occurring on or via computer elements (including the asserted APIs, and the communications between the platform and the user device/third party resource provider computing systems effectuated thereby) does not render that step or process non-abstract, nor does that alone render a claim subject matter eligible. While the APIs, user device, and third party resource provider computing systems are non-abstract additional elements, and must be (and, indeed, have been) considered as such in Step 2A, Prong Two and Step 2B, the argued steps effectuated by these computer elements (ie: real-time initiation of availability queries to multiple third-party providers, re-formatting of heterogeneous availability data into a standardized format, and receipt of an allocation update from the resource provider) remain entirely abstract business-based steps. See, e.g., MPEP 2106.04(a)(2)(III)(C) and the aforementioned Alice.
Regarding the arguments related to Step 2A, Prong Two standards, Applicant asserts the purported “technical challenges” of “[t]hird-party provider systems use disparate data formats and API structures,” “[r]esource availability changes asynchronously across multiple independent systems,” “[r]eal-time synchronization is required to prevent stale data and allocation conflicts,” and “[s]tate changes at provider systems must be propagated back to the platform,” seemingly summarizing these as “the technical problem of maintaining consistent resource state across distributed systems.” Again ignoring the 112(a) rejections stemming from the original disclosure’s failure to provide proper support for any of the presently amended limitations which purportedly solve these challenges, in the context of the present invention none of these listed challenges/problems are in fact technical in nature, nor is Applicant’s solutions to these problems technological; rather, both these challenges and solutions as argued merely cloak broader, abstract problems in narrower technological language. For example, the above-quoted challenges may alternatively be discussed as differences in record keeping between a resource offering and reservation service and the provider of the resources offered by said service. As has been well-settled since Alice, merely claiming effectuation of abstract processes on a computer neither prevents the recitation of abstract ideas nor evidences an integration of such abstract ideas into a practical application. It is additionally well-settled that mere automation of a manual process is insufficient to show a technological improvement (see 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)).
The solutions described by Applicant in these arguments likewise merely couch abstract processes in technological language. Regarding one asserted solution, Applicant merely argues the abstract process of checking in with resource providers to ensure accurate representation of resource availability at the time of addressing a received reservation request in terms of high-level technological implementation, particularly in relation to separate computer devices for said reservation service and resource provider(s) and API-based communication therebetween; yet the solution itself remains an abstract business process. Similarly regarding another asserted solution, Applicant merely argues the abstract process of modifying the format(s) in which other entities store information to a singular format in which an entity receiving such information in terms of high-level technological implementation, particularly in relation to the receipt of such information via API-based communication and storage of such re-formatted information in computer hardware (as opposed to, say, a ledger); yet there is nothing inherently technological about re-organizing the way received information is recorded by the receiving entity. This is in stark contrast to the DDR Holdings case referenced by Applicant, which, while Applicant is correct in pointing out said case makes clear that “even though the abstract idea may have pre-Internet analogues,” the argument that the present invention solves any such technology-rooted problems by way of such technology-rooted solutions is inaccurate. In said case, the invention provided modified hyperlink functionality to prevent ad-based redirection of traffic and business away from a host site to third-party merchant websites. This improved the manner in which websites and links presented thereon function, an improvement of a technology itself rather than an abstract business concept. Applicant cannot say the present invention does the same, instead merely claiming computer implementation of an abstract solution to abstract problems (as explained above).
Applicant’s present arguments contain a similar high-level analogy between the present invention and another piece of caselaw (the McRO case) in similar fashion to the above-addressed DDR Holdings, each of which fails for similar reasons, e.g., failure to properly distinguish between abstract ideas/problems/solutions and non-abstract ones. Regarding McRO, it is not entirely clear what Applicant intends by “a generic API call,” but merely specifying the abstract context of “a plurality of real-time availability queries directed to a plurality of third party resource provider[s]” does nothing to illustrate either a technological problem or a technological solution within the meaning of the 101 subject matter eligibility analysis. Similarly, what Applicant intends by “generic data processing” and “generic communication” not entirely clear, but these are not the standard for an improvement to a technology. Indeed, there are myriad pieces of caselaw making it abundantly clear that data processing/analysis/communication is an abstract endeavor (see, e.g., FairWarning IP, LLC v. Iatric Sys., Inc., 839 F.3d 1089, 1093-94 (Fed. Cir. 2016), SAP Am., Inc. v. InvestPic, LLC, 898 F.3d 1161, 127 U.S.P.Q.2d 1597 (Fed. Cir. 2018), Univ. of Fla. Rsch. Found., Inc. v. Gen. Elec. Co., 916 F.3d 1363 (Fed. Cir. 2019), Beteiro, LLC v. DraftKings, Inc., 104 F.4th 1350, 1356 (Fed. Cir. 2024), etc.). See also the myriad examples of data processing limitations, even those performed by computers, which are nonetheless found to recite abstract ideas in MPEP 2106.04(a)(2) and the Examples set forth in the most recent PEG Updates. Merely providing abstract contexts for these data processings (ie: standardizing received information into a common format for recording) and communications (ie: a state change update communicated from a resource provider to a reservation service) do not make this otherwise, whether or not these contexts may be considered “generic.” This is a far cry from the technological improvement to computer-automated facial animations set forth in McRO.
Similar to the above problems and solutions of independent Claim 44, Applicant’s arguments regarding the present amendments to Claim 45 are similarly unpersuasive. Again ignoring the lack of proper 112(a) support for the present amendments to Claim 45 and the consequent requirement to remove such new matter, the argued functionality thereof likewise merely claims the effectuation of abstract ideas (ie: recording of a “state change” of an allocated resource by the provider of said resource, and the communication of this status update to the service provider by way of an “allocation update” message) by way of a technological implementation (ie: this abstract communication occurs via a provider-side callback API or webhook).
Due to the abstract nature of these problems and solutions, Applicant’s arguments fail to evidence a technological solution. As already explained in the previous Office Action, 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.” As also already explained in the previous Office Action, “‘the challenge of coordinating resources across distributed third-party providers’ is not a technological problem, but an abstract, business-related problem. Calling this a ‘technical solution’ in the present arguments does not make it so. Indeed, the solution provided in the present claims is a broader, abstract solution to this abstract problem. Essentially, the purported solution this abstract problem…is to, upon receipt of a request for a set of resources, to check with various third-party providers as to the present availability of a variety of resources which might be used to make up the set of resources to provide to the requesting user. There is nothing inherently technological about this, and these same steps might be accomplished manually to achieve the same results.” This is equally true here, even in view of the present amendments to the claims: none of the problems or solutions argued by Applicant are in fact technological in nature, as all exist in broader form absent any of the recited technological elements, and all solutions may be accomplished in the same way manually absent any of the recited technological elements. As also explained in the previous Office Action, claiming the effectuation of such abstract solutions by way of computer elements and electronic communications neither integrates a judicial exception into a practical application nor evidences an inventive concept (see the Final Rejection of 6/24/2025, particularly in relation to the Intellectual Ventures case, for more information).
Even considering the technical additional elements themselves and how they function together absent the abstract aspects of the argued functionality (ie: the API-based call-and-response queries effectuated to update stored data in one computer with data from other, remote computers – both in terms of the argued functionalities of Claims 44 and 45), this likewise fails to illustrate a technological improvement of the present invention (even when considered “as an ordered combination” as argued). As explained above and previously, these additional elements in the context of the claim as a whole merely effectuate computer-based implementation of the above-discussed abstract solutions to abstract problems (ie: in the context of the claim as a whole, these elements constitute mere instructions to apply a judicial exception, e.g., using computers as a tool to perform an abstract idea – see MPEP 2106.05(f)). As also explained in the previous Office Action, “the API itself is not improved in this invention, and digital transmission of information between multiple computer systems was so basic and ubiquitous at the effective filing date of the present invention that no person of ordinary skill in the art could reasonably conclude that coordination between the platform and systems of third-party providers to be an improvement to technology.”
While Applicant appears to attempt to refute this explanation, made particularly in relation to an unpersuasive argument of “a specialized API structure” in the previous Office Action, by attempting to shift the goalposts of this previously argued improvement to APIs to “how distributed systems coordinate real-time resource availability across heterogeneous providers.” Despite this attempt to shift the goalposts of the argued improvement to technology, this previous explanation is not refuted by Applicant’s arguments and continues to apply to the invention as presently claimed and argued. Applicant’s arguments against this previous explanation appears to miss that it remains true that APIs and their use in data checks between disparate systems existed and were widely used well-prior to Applicant’s data of filing, which refutes both Applicant’s previously argued improvements to APIs themselves as well as Applicant’s presently argued improvements to real-time data checks between remote computers. These API-based communications between disparate computers are not “an improved distributed computing technique,” but rather represent a core and exceedingly common function of APIs prior to Applicant’s filing date. Applicant has not invented these API-based communication techniques, but instead merely applies these pre-existing techniques to a particular abstract, commercial field of use (availability checks and status updates between an aggregate resource reservation service and the individual resource providers whose resources are offered by the aggregate resource reservation service). As such, even if such API-based communications could have been considered an improvement to a technology in the distant past (e.g., in the 1990s, when such web-based APIs were first developed), one of ordinary skill in the art could not reasonably conclude that this argued functionality represents an improvement to a technology as of Applicant’s effective filing date.
As an aside, the previously argued “specialized API structure” (re-framed presently as “structured API communications”) finds no more support in the claims as presently amended than in the previous form of the claims as well as the original disclosure, which instead contains no more than three vague and high-level mentions of the use of generic APIs, absent any technical details as to how these APIs function or how the presently claimed/described APIs might differ from/improve upon any standard API (aka, constitute a “specialized API”) at Applicant’s date of filing. See Paragraphs 0041, 0069, and 0078 as filed. Relatedly, these scant passages (on top of the foundational support-based shortcomings thereof discussed in the 112(a) rejections below) fail to meet the evidentiary standards for illustrating an improvement to a technology set forth in MPEP 2106.04(d)(1). The above-argued problems and solutions (even if they were technological in nature, which, to be clear, they are not) are never mentioned in these passages in relation to API-based functionality, nor do they appear to be discussed in broader form anywhere else in the original disclosure so far as Examiner can see. As such, the majority of Applicants arguments regarding improvements to technology under Step 2A, Prong Two appears to be no more than attorney argument, having no basis in the original disclosure, 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)).
Claim Rejections – 35 USC § 102
Applicant’s arguments regarding the 102 analysis have been considered and are unpersuasive.
Regarding the asserted initiation, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems, Applicant essentially repeats the same unpersuasive arguments asserted previously when this functionality was argued but not properly embodied, and is refuted by the same explanation provided in the Final Rejection of 6/24/2025. Despite said previous explanation identifying to Applicant that the presently repeated reference to the scraping disclosure found in Paragraph 0005 of Patel is part of Patel’s Background section, describing the state of the art at the time of Patel’s filing rather than a description of the invention set forth in Patel, Applicant repeats this argument presently, erroneously asserting this as evidence that the invention of Patel is limited to such data scraping techniques. This is no more true now than when addressed previously. Rather, as explained in said Final Rejection, “Indeed, in at least Paragraph 0052 of Patel, embodiments are described wherein third-party providers (such as online travel agencies and individual resource providers) are directly queried by the system and respond with applicable available resources via search APIs. This is specifically and explicitly done in reaction to the user’s request and search criteria, as part of ‘mixture query instructions;’ thus, even considering what Applicant argues is claimed rather than what is actually claimed, this is performed ‘in real-time’ and ‘at a time of processing of the request.’ Indeed, these search APIs were previously cited in relation to different limitations in the previous Office Action, which Applicant appears to ignore in these present arguments.” This previously-provided explanation continues to fully refute Applicant’s arguments in relation to this feature.
Regarding Applicant’s more general argument regarding the APIs disclosed in Patel, this argument is refuted by the same explanation provided previously and directly above. Applicant’s continued assertion of this feature in Patel as stemming from “scraping and caching” is no more true here than above and previously, and Applicant yet again references content of Patel’s Background section (ie: Paragraphs 0004-0005), which, as has now been explained in multiple Office Actions, describes the state of the art at the time of Patel’s filing rather than the invention of Patel itself. Rather, as explained above and previously, Paragraph 0052 of Patel explicitly discloses embodiments where this availability data is gathered via APIs as part of the search query process, nor is Patel limited to the asserted “booking APIs” disclosed elsewhere in Patel. Continuing to ignore this disclosure and the previous explanation provided in relation thereto does not provide a persuasive argument.
Regarding the asserted and newly claimed/argued normalizing of heterogeneous availability data, Applicant’s arguments in relation thereto are rendered moot by the updated 103 rejections below. Examiner notes again that this feature represents new matter, and as such requires removal as per the 112(a) written description rejection in relation thereto below.
Claim Rejections – 35 USC § 103
Applicant’s arguments regarding the 103 analysis have been considered and are unpersuasive.
Regarding Applicant’s arguments for Claims 45-46 and 48-49 based on purported deficiencies of Patel regarding Claim 44 (upon which each of these claims depend), those arguments are either untrue or are rendered moot in view of the updated 103 rejection of Claim 44.
Regarding the arguments related to the amended features of Claim 45, again ignoring that this amendment fails to find proper support in the original disclosure and thus requires removal as per the 112(a) written description rejection below, this argument is rendered moot in view of the updated 103 rejection of Claim 45 below.
Claim Rejections – 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 44-49 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 44 contains the following limitations: “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 and initiates, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems” and “receiving, via the API, the set of available resources determined in real-time by the platform based on responses to the plurality of real-time availability queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available, the set of resource providers including 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.” The real-time availability queries at the time of request processing claimed in these limitations lacks proper support in the original disclosure. Availability checks for the reservable resources are disclosed in at least the Abstract and Paragraphs 0004, 0021-0022, 0041, and 0059 as filed; however, none of these passages (nor any other content to be found in the original disclosure) discloses such availability checks occurring in “real-time” or “at the time of processing the request” as claimed (as noted in the Final Rejection of 6/24/2025, Paragraph 0060 contains the only mention of real-time performance in the entire original disclosure, but relates to the allocation update functionality of Claim 45 rather than the above-quoted limitations of Claim 44) , nor API-based implementation of these availability checks (APIs are solely mentioned in Paragraphs 0041, 0069, and 0078, none of which disclose API-based execution of these availability checks). More granularly, what is described in the original disclosure is providing a customer with a list of available resources in response to a reservation request (see, e.g., Paragraphs 0066, 0077; Figs. 3A-3B, 4), but nothing to indicate the claimed availability queries sent to various resource providers occurs at this time. In other words, there is nothing in the original disclosure to indicate that such availability queries occur at a different, prior time (such as prior to the receipt of a reservation request from a customer), and the stored results of these earlier queries (rather than the performance of these queries themselves) are then used in “real-time” or “at the time of processing the request.” See the Final Rejection of 6/24/2025 for more information. As such, this functionality constitutes new matter and violates written description requirements. Claims 45-49 are rejected based on their dependence upon Claim 44.
Claim 44 contains the following limitation: “normalizing heterogeneous availability data returned from the plurality of third party resource providers into a unified resource representation maintained by the platform.” This functionality lacks proper support in the original disclosure. Normally, Examiner would reference passages of the original disclosure to make clear the distinction between the content thereof and what is claimed, but the original disclosure does not appear to contain any such relevant passages for Examiner to cite. Rather, this data formatting normalization functionality appears to have no basis whatsoever in the original disclosure. As such, this functionality constitutes new matter and violates written description requirements. Claims 45-49 are rejected based on their dependence upon Claim 44.
Claim 45 contains the following limitation: “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 via a provider-side callback API or webhook.” This functionality lacks proper support in the original disclosure. This functionality is described in Paragraphs 0041, 0060, 0076, 0087, and 0091, as well as Figs. 3A-3B and 4. These passages, in combination, support the receipt of a reservation update from a resource provider to the platform, said receipt occurring either by way of API or website generated by the platform (to which the resource provider may be granted access), after which either the platform or the resource provider may provide the customer with an indication of this reservation update. However, nothing in these passages or elsewhere discloses the receipt of this reservation update from the resource provider to the platform occurring by way of the narrower claimed embodiments of “a provider-side callback API or webhook,” neither of which appear to be supported by the original disclosure at all much less in the context claimed. As such, this functionality constitutes new matter and violates written description requirements. Claim 46 is rejected based on its dependence upon Claim 45.
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: “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 and initiates, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems.” Within this limitation, the application of the language “initiates, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems” is circular and nonsensical, as the processing of the request (and the associated initiation of a plurality of real-time availability requests) cannot be part of the request itself as claimed (ie: the root language of “wherein requesting the set of available resources includes…”). For the purposes of this examination, this limitation will be interpreted as the following two distinct limitations: “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” and “initiating, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems.” Claims 45-49 are rejected based on 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 44, 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; initiating, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource providers; receiving the set of available resources determined in real-time by the platform based on responses to the plurality of real-time availability queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available, the set of resource providers including 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; normalizing heterogeneous availability data returned from the plurality of third party resource providers into a unified resource representation maintained by the platform; generating a list comprising one or more resources from the set of available resources for selection by the user of the computing device; receiving user selection of a resource from the one or more resources; providing a resource request indicating the selected resource as a requested resource from the platform; receiving 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; initiating, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource providers; receiving the set of available resources determined in real-time by the platform based on responses to the plurality of real-time availability queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available, the set of resource providers including 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; normalizing heterogeneous availability data returned from the plurality of third party resource providers into a unified resource representation maintained by the platform; generating a list comprising one or more resources from the set of available resources for selection by the user of the computing device; receiving user selection of a resource from the one or more resources; providing a resource request indicating the selected resource as a requested resource from the platform; receiving 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)).
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. 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, and generating a user interface comprising one or more selectable elements. In the context of the claim as a whole, these 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 (an abstract idea in the form of a certain method of organizing human activity and a mental process); 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) via a provider-side callback API or webhook (mere instructions to apply a judicial exception); 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 Rosner et al (PGPub 20160035019) (hereafter, “Rosner”).
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;);
initiating, at a time of processing the request, a plurality of real-time availability queries directed to a plurality of third party resource provider computing systems (¶ 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);
receiving, via the API, the set of available resources determined in real-time by the platform based on responses to the plurality of real-time availability queries, wherein each resource of the set of resources has an associated set of resource providers via which the resource is available, the set of resource providers including 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);
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 (¶ 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);
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 does not explicitly disclose but Rosner does disclose normalizing heterogeneous availability data returned from the plurality of third party resource providers into a unified resource representation maintained by the platform (¶ 0023, 0030, 0083; Figs. 1, 7; the back-end portion of the host server can gather information and normalize the data so as to convert them into a common format, suitable for further processing; the intelligence information can include, for example, room availability and type, gathered or passively received from a plurality of inventory servers; the back-end portion of the host server maintains the repository by updating it with the latest information).
It 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-based data format normalization techniques of Rosner 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 Rosner 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 47, Patel in view of Rosner 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)).
Claim 48 is rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Rosner and Bellotti et al (PGPub 20180238694) (hereafter, “Bellotti”).
Regarding Claim 48, Patel in view of Rosner 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 the Patel and Rosner 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 and Rosner 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 and Rosner), 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.
Claims 45-46 are rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Rosner, Bellotti, and Kapadia (PGPub 20200202402) (hereafter, “Kapadia”).
Regarding Claim 45, Patel 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 (¶ 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). Patel does not explicitly disclose but Kapadia does disclose the allocation update being generated in response to a state change received from the resource provider via a provider-side callback API or webhook (¶ 0029; the check-in platform interface communicates with the salon service API; the salon service API may keep the updated information of all salons, e.g., the real-time availability of a salon, available service providers of a salon, specialties of a salon, etc.).
Patel does not explicitly disclose but Bellotti does disclose 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 and Rosner 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 resource reservation status update structure and functionality of Kapadia with the resource reservation system of Patel and Rosner 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 Kapadia are applicable to the base device (Patel and Rosner), 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 Rosner, Bellotti, and Kapadia 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.
Claim 49 is rejected under 35 U.S.C. 103 as being unpatentable over Patel in view of Rosner, Bellotti, and Eklund (PGPub 20170270556) (hereafter, “Eklund”).
Regarding Claim 49, Patel in view of Rosner discloses the limitations of Claim 44. 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 Patel, Rosner, and Bellotti remains the same as for Claim 48. 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.
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
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