DETAILED ACTION
Notice of 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 the Application
Claims 1-20 have been examined in this application. This communication is the first action on the merits.
Priority
This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63/632,994 filed on April 11, 2024.
Information Disclosure Statement
The Information Disclosure Statements filed on 4/10/2025 and 6/26/2025 have been considered.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
Claim 1 recites “A non-transitory computer readable medium storing a computer-executable program code instructions…” but appears it should recite “A non-transitory computer readable medium storing [[a]] computer-executable program code instructions…”
Claim 1 recites “via the directional bridge” in two instances, however, it appears they should recite “via the bidirectional bridge” consistent with earlier limitations in the claim. This limitation is interpreted as though it recites “the bidirectional bridge” for the purpose of further examination.
Claim 11 recites “generating a primary order from the order date” which appears to be a typo and should recite “the order data”
Claim 11 recites “modifying the primary order via the OrMS to include the first change” but appears that it should recite “modifying the primary order via the OrMS to include the first change data”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“order data received via an order-enabled channel” of claim 1
“generating a primary order via an order management system (OrMS),” “determining, via the OrMS, whether the order data includes operational travel information,” “generating a secondary order…via the OrMS,” “receiving first change data…via the OrMS,” “determining, via the OrMS…,” “modifying the primary order via the OrMS,” “modifying the primary order via the OrMS,” “determining, via the OrMS,” “modifying the secondary order via the OrMS,” “receiving third change data…via the OrMS,” “modifying the secondary order via the OrMS,” “determining, via the OrMS,” and “modifying the primary order via the OrMS” of claim 1
“communicating the secondary PNR to an airline passenger service system (PSS) via a bidirectional bridge,” “retrieving, via the bidirectional bridge, a primary PNR” “communicating the first operational travel information change data to the airline PSS via the bidirectional bridge,” “retrieving second change data related to the primary PNR from the airline PSS via the directional bridge” (note that “directional bridge” appears to be intended to recite “bidirectional bridge” as per claim objection above), “communicating the third operational travel information change data to the airline PSS via the bidirectional bridge,” and “retrieving fourth change data related to the secondary PNR from the airline PSS via the directional bridge” of claim 1
“using the OrMS, generating a primary order,” “using the OrMS, generating a secondary passenger name record (PNR),” receiving, via the OrMS, first change data,” “using the OrMS, determining…,” “modifying the primary order via the OrMS,” “using the OrMS, determining…,” and “modifying the primary order via the OrMS” of claim 11
“using a bidirectional bridge, communicating the secondary PNR to an airline passenger service system (PSS),” “using the bidirectional bridge, communicating the first operational travel information change data,” and “using the bidirectional bridge, retrieving second change data” of claim 11
“using a bidirectional bridge providing communication between an order management system (OrMS) and an airline passenger service system (PSS), retrieving a primary passenger name record (PNR),” “using the bidirectional bridge, retrieving first change data,” and “using the bidirectional bridge, communicating the second operational travel information change data” of claim 16
“using the OrMS, generating a secondary order,” “using the OrMS, determining…,” “modifying the secondary order via the OrMS,” “receiving, via the OrMS, second change data,” “using the OrMS, determining…,” and “modifying the secondary order via the OrMS” of claim 16
“a primary passenger name record (PNR) created by the airline PSS” of claim 16
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
The corresponding structure for the “order-enabled channel” is described in ¶ 0016 of the specification filed 4/10/2025.
The corresponding structure for the “order management system (OrMS)” is described in ¶ 0016-0017 of the specification.
The corresponding structure for the “bidirectional bridge” is described in Figs. 2-4 of the specification.
The corresponding structure for the “airline PSS” is described in ¶ 0016-0017, ¶ 0020-0021, ¶ 0032, ¶ 0035, and ¶ 0037 of the specification.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Step 1:
Claims 1-9 recite “A non-transitory computer readable medium storing a computer-executable program code instructions, wherein the computer-executable program code instructions include instructions for…” (i.e. an article of manufacture); claims 10-20 recite “A method…” (i.e. a process). These claims fall under one of the four categories of statutory subject matter and as a result, pass Step 1 of the subject matter eligibility test. However, “Determining that a claim falls within one of the four enumerated categories of patentable subject matter recited in 35 U.S.C. 101 (i.e., process, machine, manufacture, or composition of matter) in Step 1 does not end the eligibility analysis, because claims directed to nothing more than abstract ideas (such as a mathematical formula or equation), natural phenomena, and laws of nature are not eligible for patent protection.” See MPEP 2106.04. Accordingly, the examiner continues the subject matter eligibility analysis below.
Step 2A Prong One:
Independent claim 1 recites limitations for:
receiving…order data received…from a traveler, airline, or third-party…;
generating a primary order…
determining…whether the order data includes operational travel information;
generating a secondary passenger name record (PNR) from the primary order…and communicating the secondary PNR to an airline passenger service system (PSS)…if the order data includes the operational travel information;
retrieving…a primary PNR;
generating a secondary order from the primary PNR…; and
(i) receiving first change data related to the primary order…;
determining…whether the first change data includes first operational travel information change data; and
modifying the primary order…to include the first change data and not communicating the first operational travel information change data…if the first change data does not include the first operational travel information change data; or
modifying the primary order…to include the first change data and communicating the first operational travel information change data…if the first change data includes the first operational travel information change data; or
(ii) retrieving second change data related to the primary PNR from the airline PSS…to the OrMS;
determining…whether the second change data includes second operational travel information change data; and
modifying the secondary order…to include the second operational travel information change data if the second change data includes the second operational travel information change data; or
(iii) receiving third change data related to the secondary order…;
determining…whether the third change data includes third operational travel information change data; and
modifying the secondary order…to include the third change data;
communicating the third operational travel information change data…if the third change data includes the third operational travel information change data; or
(iv) retrieving fourth change data related to the secondary PNR from the airlines PSS…to the OrMS;
determining…whether the fourth change data includes fourth operational travel information change data; and
modifying the primary order…to include the fourth operational travel information change data if the fourth change data includes the fourth operational travel information change data
Independent claim 11 recites similar limitations for:
receiving order data at an order management system (OrMS);
…generating a primary order from the order date;
extracting…operational travel information from the order data;
…generating a secondary passenger name record (PNR) from the operational travel information;
…communicating the secondary PNR to an airline passenger service system (PSS); and
(i) receiving…first change data related to the primary order;
…determining whether the first change data includes first operational travel information change data;
modifying the primary order…to include the first change; and
if the first change data is determined to include the first operational travel information change data…communicating the first operational travel information change data to the airline PSS; or
(ii) …retrieving second change data from the airlines PSS to the OrMS;
…determining whether the second change data includes second operational travel information change data; and
if the second change data is determined to include the second operational travel information change data, modifying the primary order…to include the second operational travel information change data
Independent claim 16 recites similar limitations for:
…providing communication between an order management system (OrMS) and an airlines passenger service system (PSS), retrieving a primary passenger name record (PNR) created by the airline PSS;
…generating a secondary order from the primary PNR; and
(i) …retrieving first change data from the airlines PSS to the OrMS;
…determining whether the first change data includes first operational travel information change data; and
if the first change data is determined to include the first operational travel information change data, modifying the secondary order…to include the first operational travel information change data; or
(ii) receiving…second change data related to the secondary order;
…determining whether the second change data includes second operational travel information change data;
modifying the secondary order…to include the second change; and
if the second change data is determined to include the second operational travel information change data…communicating the second operational travel information change data to the airline PSS
The limitations of independent claims 1, 11 and 16 above (in light of the specification) are determined to recite an abstract idea (characterized as receiving and managing order data, PNR data, and receiving and managing changes to the order data/PNR data between an order management system and an airline passenger service system based on travel information) for the reasons discussed in the following continued Step 2A Prong One analysis. Note that “An abstract idea can generally be described at different levels of abstraction.” Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1240-41 (Fed. Cir. 2016).
As per MPEP 2106.04(a)(2)(II), claim limitations which recite commercial or legal interactions (including agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations) or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions) fall into the “certain methods of organizing human activity” category of judicial exceptions. The processes described by the limitations above amount to a commercial interaction and/or managing interactions between people (i.e. receiving and managing order data, PNR data, and receiving and managing changes to the order data/PNR data between an order management system and an airline passenger service system based on determined operational travel information). Therefore, the claims fall into the “certain methods of organizing human activity” grouping of abstract ideas.
As described in MPEP 2106.04(a)(2)(III), “[T]he "mental processes" abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes include observations, evaluations, judgments, and opinions.” and “If a claim recites a limitation that can practically be performed in the human mind, with or without the use of a physical aid such as pen and paper, the limitation falls within the mental processes grouping, and the claim recites an abstract idea.” The limitations recited by the representative independent claims 1, 11, and 16 above, under the broadest reasonable interpretation and but for the use of generic computer components, cover concepts (e.g. observation, evaluation, judgment, and opinion) that can reasonably be performed in the human mind or by the human mind with the aid of simple tools such as pen and paper to issue communications. For example, the “receiving…order data,” “retrieving…a primary PNR,” “receiving” or “retrieving” first change data,” steps describe observations, while the “determining” whether order data/order change data includes operational travel information or operational travel information change data, “not communicating,” “extracting…operational travel information,” steps would be considered evaluations, judgments, and/or opinions. Furthermore, “generating a primary order,” “generating a secondary passenger name record…and communicating the secondary PNR,” “generating a secondary order,” “modifying” the primary or secondary order, and “communicating” change information describes mental processes (writing down/communicating an observation, evaluation, judgment, and/or opinion) that, but for the recitation of generic computer components, could otherwise be carried out using pen and paper via a notepad/ledger or written communications. Therefore, as the processes above described by the representative independent claims 1, 11, and 16 can be characterized as mental processes (i.e. observation, evaluation, judgment, and opinion), but for the recitation of generic computer components in the claims, the claims fall under the “mental processes” category of judicial exceptions (i.e. abstract ideas).
As claims 1, 11, and 16 are identified by the examiner as reciting concepts that fall under more than one abstract idea grouping (i.e. “certain methods or organizing human activity” and “mental processes”), the examiner considers the limitations together as a single abstract idea for the purposes of the Step 2A Prong Two and Step 2B analysis, in accordance with MPEP 2106.04(II)(B).
Step 2A Prong Two:
Claims 1, 11 and 16 recite the following additional elements:
“A non-transitory computer readable medium storing a computer-executable program code instructions, wherein the computer-executable program code instructions include instructions for…” of claim 1
a first computing device (e.g. “at a first computing device”) and “a traveler, airline, or third-party device” of claim 1
“an order-enabled channel” of claim 1
an order management system (OrMS) (e.g. “via an order management system (OrMS),” “via the OrMS,” “to the OrMS,” “at an order management system (OrMS),” “using the OrMS”) of claims 1, 11, and 16 (to the extent the OrMS is a computer-implemented OrMS performing computer functions)
an airline passenger service system (PSS) (e.g. “to an airline passenger service system (PSS),” “to the airline PSS,” “from the airline PSS”) of claims 1, 11, and 16 (to any extent this is a computer-implemented PSS performing computer functions)
a bidirectional bridge (e.g. “via a bidirectional bridge,” “using a bidirectional bridge,” “using a bidirectional bridge providing communication between an order management system (OrMS) and an airline passenger service system (PSS)”) of claims 1, 11, and 16
The judicial exception (i.e. abstract idea) recited in claims 1, 11, and 16 is not integrated into a practical application because the claims recite mere instructions to apply the abstract idea (i.e. receiving and managing order data, PNR data, and receiving and managing changes to the order data/PNR data between an order management system and an airline passenger service system based on determined operational travel information) using generic computers/computer components (i.e. “A non-transitory computer readable medium storing a computer-executable program code instructions, wherein the computer-executable program code instructions include instructions for…,” a first computing device, and a traveler, airline, or third-party device, and an order-enabled channel of claim 1, and an order management system/OrMS, an airlines passenger service system/PSS, and a bidirectional bridge of claims 1, 11, and 16). The various limitations for performing the abstract functions identified above “using,” “via,” or “by” the OrMS, PSS, and bidirectional bridge does not amount to anything more than instructions to “apply it” (i.e. apply the abstract idea) using generic computer components. See MPEP 2106.05(f), showing “[C]laims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp.”
The claims recite a series of limitations for generally receiving or communicating data (e.g. order data, PNR data, and change data) by or between an order-enabled channel (specific to claim 1), and the OrMS and the airline PSS via a bidirectional bridge which, under the broadest reasonable interpretation, reads on receiving and transmitting data over a network, and therefore merely describes the use of generic computers (the order management system, the airline passenger services system, and the bidirectional bridge) in their ordinary capacity to receive and transmit data. The order-enabled channel, order management system, airline PSS and the bidirectional bridge are recited at a high level of generality, and the particulars of these elements are not described in any detail to suggest an improvement to how computers receive or transmit data, but instead simply amounts to performing generic data communications over a network between two computers/computer systems. The specification does not indicate that any of the additional elements above amount to anything more the generic computer implementation used to carry out the abstract idea (see spec. at ¶ 0016-0017, ¶ 0040). The use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application, but instead further indicates that the claims recite mere instructions apply the abstract idea using a generic computer or computer components.
Therefore, because the claims, considered as a whole, do not recite anything that integrates the abstract idea into a practical application, the claims are directed to an abstract idea.
Step 2B:
Claims 1, 11, and 16 do not include additional elements, whether considered alone or as an ordered combination, that are sufficient to amount to significantly more than the judicial exception (i.e. abstract idea) because as mentioned above, the claims recite mere instructions to apply the abstract idea (i.e. receiving and managing order data, PNR data, and receiving and managing changes to the order data/PNR data between an order management system and an airline passenger service system based on determined operational travel information) using generic computers/computer components (i.e. “A non-transitory computer readable medium storing a computer-executable program code instructions, wherein the computer-executable program code instructions include instructions for…,” a first computing device, and a traveler, airline, or third-party device, and an order-enabled channel of claim 1, and an order management system/OrMS, an airlines passenger service system/PSS, and a bidirectional bridge of claims 1, 11, and 16). The various limitations for performing the abstract functions identified above “using,” “via,” or “by” the OrMS, PSS, and bidirectional bridge does not amount to anything more than instructions to “apply it” (i.e. apply the abstract idea) using generic computer components. See MPEP 2106.05(f), showing “[C]laims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible. Alice Corp.”
As above, the claims recite a number of limitations for receiving or communicating data (e.g. order data, PNR data, and change data) by or between an order-enabled channel (specific to claim 1), and the OrMS and the airline PSS via a bidirectional bridge, under the broadest reasonable interpretation, reads on receiving and transmitting data over a network, and therefore describes the use of generic computers (order enabled channel, the order management system, the airline passenger services system, and the bidirectional bridge) in their ordinary capacity to receive and transmit data. The order-enabled channel, order management system, airline PSS and the bidirectional bridge are recited at a high level of generality, and the particulars of these elements are not described in any detail to suggest an improvement to how computers receive or transmit data, but instead simply amounts to performing generic data communications over a network between two computers/computer systems. The specification does not indicate that any of the additional elements above amount to anything more the generic computer implementation used to carry out the abstract idea (see spec. at ¶ 0016-0017, ¶ 0040). The use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not add significantly more than the abstract idea, but instead further indicates that the claims recite mere instructions apply the abstract idea using a generic computer or computer components.
Further, the courts have recognized such limitations for “Receiving or transmitting data over a network, e.g., using the Internet to gather data” as well-understood, routine, or conventional activity. See MPEP 2106.04(d)(II), citing Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network). Though the claims do not explicitly recite the “retrieving” steps as involving a memory, the examiner notes that the courts have also identified “Storing and retrieving information in memory” as well-understood, routine and conventional. See MPEP 2106.04(d)(II), citing Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93.
Considering the additional elements as an ordered combination does not alter the analysis above, or add anything that amounts to significantly more than an abstract idea.
Dependent Claims 2-10, 12-15, and 17-20:
Dependent claims 2-10, 12-15, and 17-20 are directed to the same abstract idea as independent claims 1, 11 and 16 above as they do not recite anything that integrates the abstract idea into a practical application or amounts to significantly more than the abstract idea.
Dependent claims 2-9, 12-15, and 17-20 do not add any additional elements beyond those already addressed above, but merely further describe the abstract idea above by reciting limitations for:
“receiving the first change data” (claims 2, 12)
further describing the first change data and only communicating some of the first change data (claims 3, 13)
“retrieving the second change data” (claims 4, 14)
further describing second change data and modifying the secondary order (claim 5) or primary order (claim 15)
“receiving the third change data” (claim 6)
further describing the third change data and only communicating some of the third change data (claim 7)
“retrieving the fourth change data” (claim 8)
further describing the fourth change data and modifying the primary order (claim 9)
“retrieving the first change data” (claim 17)
further describing the first change data and modifying the secondary order (claim 18)
“receiving the second change data” (claim 19)
further describing the second change data and only communication some of the second change data (claim 20)
These further limitations are (in claims 1, 3, 4, 6, and 7) merely described as being applied using the same generic computers/computer components (i.e. “instructions for” of claims 1, 4, and 6; the airlines PSS of claims 3 and 7) addressed above.
Furthermore, claim 10 recites “A method comprising executing the non-transitory computer readable medium” – however, “executing the non-transitory computer readable medium” recites generic computer implementation to apply the method (the abstract idea) that does not integrate the abstract idea into a practical application or add significantly more.
Therefore, claims 1-20 are ineligible under § 101.
Claim Rejections - 35 USC § 102
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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by US 20230147898 A1 to Yin et al. (Yin).
Claim 1: Yin teaches:
A non-transitory computer readable medium storing a computer-executable program code instructions, wherein the computer-executable program code instructions include instructions for (Yin: ¶ 0005, ¶ 0036, ¶ 0039-0040 showing computer-readable medium storing code/instructions executable by a controller/processor):
receiving, at a first computing device (Yin: ¶ 0035-0036, ¶ 0043, Fig. 2, and Fig. 4 showing device 201 including controller 220), order data received via an order-enabled channel from a traveler, airline, or third-party device (Yin: ¶ 0043 “the controller 220 and/or the device 201 receives, from one of a first client device 101 and a second client device 102, booking data. The booking data may comprise a request to purchase a product, such as an airline ticket, and the like, and/or any other suitable type of product”; ¶ 0025-0027 and Fig. 1 showing the first client device 101 corresponds to a computing device or a mobile device of a user wishing to book and/or purchase a product via an associated application, i.e. traveler, and the second client device 102 corresponds to a computing device or terminal device operated by a travel agency or airline, i.e. third party or an airline; also see ¶ 0040, ¶ 0078 and ¶ 0085);
generating a primary order via an order management system (OrMS) (Yin: ¶ 0049 and ¶ 0078-0079 showing after order management system (OMS 111) of device 201 receives booking data, the OMS generates order data, i.e. a primary order, which includes any suitable data associated with the booking data including, but not limited to, fields populated with product attributes and/or client attributes as described above, the fields populated according to the booking data; see ¶ 0029 further showing the generated order data may include fields “such as product identifiers (e.g. service identifiers, item identifiers and the like), locations, dates and times corresponding to the products (e.g. flight times and other itinerary data). Other fields of the data object define client attributes, such as client identifiers (e.g. identifying the traveler, in the case of travel-related products such as the above-mentioned flights), payment data, and the like”);
determining, via the OrMS, whether the order data includes operational travel information (Yin: ¶ 0044-0049 and ¶ 0068-0069 showing the device 201 determines whether the booking data, i.e. order data, is received from a first client device based on the booking data including data that identifies the booking data as having originated at client devices operating according to an NDC standard; and ¶ 0050, ¶ 0068 showing booking data placed in a first or second order mode based on the information in the booking data, which causes corresponding PNR/ticket data to be generated, i.e. operational travel data; also see wherein as per ¶ 0029, ¶ 0049 the booking data, i.e. order data, including operational travel info and formatted according to the NDC standard is identified and used to generate data objects defining a flight, ancillary services, and/or other travel products according to the booking information and store it in the NDC format; see claim interpretation note below);
generating a secondary passenger name record (PNR) from the primary order via the OrMS and communicating the secondary PNR to an airline passenger service system (PSS) via a bidirectional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”) if the order data includes the operational travel information (Yin: ¶ 0080 “the OMS 111 transmits (e.g. at the block 310) a command 411 to the legacy system 112 which may include data from the booking data 401 and/or the order data 403 to be included in a corresponding passenger name record”; and ¶ 0050 “the controller 220 and/or the device 201 may cause the OMS 111 to communicate with the legacy system 112 to cause the legacy system 112 to generate a passenger name record at the second database 122 that includes the same and/or similar data stored in the order data, for example in respective fields, but according to a second format (such as a GDS-based format, as described above), for example stored in association with the booking data and/or a booking identifier”; see ¶ 0022 showing “In some examples, the legacy system 112 comprises a PSS,” i.e. passenger service system as defined in ¶ 0015);
retrieving, via the bidirectional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”), a primary PNR (Yin: ¶ 0085-0086 showing if booking data is received from a second client device, the legacy system of device 201 generates a PNR and ticket data, and in ¶ 0087 “To cause the OMS 111 to generate corresponding order data at the first database 121, the device 201 and/or the legacy system 112 transmits (e.g. at the block 316) a command 611 to the OMS 111 which may include data from the booking data 601 and/or the PNR 603 and/or the ticket data 604 to be included in corresponding order data. The OMS 111 (and/or the device 201) responsively generates corresponding order data 613 and stores the corresponding order data 613 at the first database 121”);
generating a secondary order from the primary PNR via the OrMS (Yin: ¶ 0087 “To cause the OMS 111 to generate corresponding order data at the first database 121, the device 201 and/or the legacy system 112 transmits (e.g. at the block 316) a command 611 to the OMS 111 which may include data from the booking data 601 and/or the PNR 603 and/or the ticket data 604 to be included in corresponding order data. The OMS 111 (and/or the device 201) responsively generates corresponding order data 613 and stores the corresponding order data 613 at the first database 121”); and
(i) receiving first change data related to the primary order via the OrMS (Yin: ¶ 0053-0056, ¶ 0064-0066 showing the controller 220 of device 201 is configured to receive booking change data related to the from the first device at the order management system/device 201, i.e. change related to the primary order from the original booking data; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
determining, via the OrMS, whether the first change data includes first operational travel information change data (Yin: ¶ 0064, ¶ 0089 showing that booking change data received at OMS may be identified as including changes to be reflected in the PNR and/or ticket data, i.e. operational travel change data, or otherwise in ¶ 0065 the booking change data may include change for which no corresponding field exists in the one or more of the passenger name record and the ticket data, i.e. non-PNR/non-operational travel data); and modifying the primary order via the OrMS to include the first change data and not communicating the first operational travel information change data to the airline PSS if the first change data does not include the first operational travel information change data (Yin: ¶ 0065 showing the change may be made only to the order information in the first database if the booking change data includes changes for which no corresponding field exists in the PNR/ticket data in the legacy system); or modifying the primary order via the OrMS to include the first change data and communicating the first operational travel information change data to the airline PSS via the bidirectional bridge if the first change data includes the first operational travel information change data (Yin: ¶ 0064, Fig. 5 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”; also see ¶ 0089); or
(ii) retrieving second change data related to the primary PNR from the airline PSS via the directional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”; also see bidirectional bridge described in Fig. 5) to the OrMS (Yin: ¶ 0055-0056 showing the legacy system receives booking change data from a second device, i.e. a change related to the primary PNR, and redirects the booking change data to the OMS – “when a second client device 102 attempts to access and make changes to the booking data, for example by transmitting, to the legacy system 112, booking change data, the legacy system 112 may redirect such booking change data to the OMS 111”; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
determining, via the OrMS, whether the second change data includes second operational travel information change data (Yin: ¶ 0055-0057 respectively showing identifying, based on the booking change data, that the booking change data should cause the order data to be changed at the first database, or otherwise, in ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”); and
modifying the secondary order via the OrMS to include the second operational travel information change data if the second change data includes the second operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database); or
(iii) receiving third change data related to the secondary order via the OrMS (Yin: ¶ 0067 showing “the controller 220 and/or the device 201, in the legacy mode for the booking data: receiving, from the first client device 101, booking change data” at the OMS; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
determining, via the OrMS, whether the third change data includes third operational travel information change data (Yin: ¶ 0067 showing that booking change data received at OMS may be identified as including changes to be reflected in the PNR and/or ticket data, i.e. operational travel change data, or otherwise in ¶ 0065 the booking change data may include change for which no corresponding field exists in the one or more of the passenger name record and the ticket data, i.e. non-PNR/non-operational travel data); and
modifying the secondary order via the OrMS to include the third change data (Yin: ¶ 0067 showing causing the corresponding order data to be changed at the first database 121 according to changes made to the one or more of the passenger name record and the ticket data at the second database 122);
communicating the third operational travel information change data to the airline PSS via the bidirectional bridge if the third change data includes the third operational travel information change data (Yin: ¶ 0066-0067 showing redirecting changes from the OMS to the legacy system, i.e. PSS, based on the booking change data; see ¶ 0033 showing bidirectional bridge for communications between the OMS and legacy system/PSS); or
(iv) retrieving fourth change data related to the secondary PNR from the airline PSS via the directional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”; also see bidirectional bridge shown in Fig. 5) to the OrMS (Yin: ¶ 0055-0057 showing the legacy system of device 201 receives booking change data from a second device, i.e. a change related to the primary PNR, and redirects the booking change data to the OMS; “when a second client device 102 attempts to access and make changes to the booking data, for example by transmitting, to the legacy system 112, booking change data, the legacy system 112 may redirect such booking change data to the OMS 111”; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
determining, via the OrMS, whether the fourth change data includes fourth operational travel information change data (Yin: ¶ 0055-0057 respectively showing identifying, based on the booking change data, that the booking change data should cause the order data to be changed at the first database, or otherwise, in ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”); and modifying the primary order via the OrMS to include the fourth operational travel information change data if the fourth change data includes the fourth operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
Claim Interpretation Notes (also applied to all subsequent claims as applicable):
The primary order, secondary order, primary PNR, and secondary PNR, are interpreted in light of the specification at [0019] (“The order is herein referred to as primary if it was created as shown and described in FIG. 2, in which cases the PNR is referred to as secondary…The order is secondary and the PNR is primary if they were created as shown and described in FIG. 3”). This indicates that the secondary order may not have any relation to the primary order and the primary PNR may not have any relation to the secondary PNR (e.g. they may refer to different orders/PNRs, based on how they were created).
Further, the claims do not specify what the “operational travel information” constitutes, and though examples are given in the specification at [0018] (“Orders and PNRs may include overlapping information, such as passenger details (e.g., name, date of birth, etc.) and travel details (e.g., flight information) (collectively referred to herein as operational travel information)”), this is not an explicit definition and still leaves the broadest reasonable interpretation open to any of the booking data (order data) disclosed by Yin, which teaches the booking data as including booking information related to travel products/flights and identifying whether this booking data is formatted in NDC or legacy (e.g. GDS) format.
Claim 2: Yin discloses claim 1. Yin further discloses:
wherein the instructions include instructions for receiving the first change data (Yin: ¶ 0053-0056, ¶ 0064-0066 showing the controller 220 of device 201 is configured to receive booking change data)
Claim 3: Yin discloses claim 2. Yin discloses:
wherein the first change data includes the first operational travel information change data and non-PNR change data (Yin: ¶ 0064-0066 showing booking change data may include both data corresponding to changes to be made to PNR/ticket data, i.e. operational travel change data, and data which does not have a corresponding field in the PNR/ticket data, i.e. non-PNR change data) and wherein communicating the first operational travel information change data to the airline PSS comprises communicating only the first operational travel information change data (Yin: ¶ 0064 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”; also see ¶ 0089)
and not the non-PNR change data (Yin: ¶ 0065-0066 showing booking change data that may “One exception to this example may be the OMS system 111 updating the corresponding order data at the first database 121 when the booking change data includes changes to the corresponding order data that will not otherwise impact the one or more of the passenger name record and the ticket data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the one or more of the passenger name record,” wherein the OMS 111 may update the corresponding order data according to the booking change data, but does not communicate the non-PNR change data)
Claim 4: Yin discloses claim 1. Yin further discloses:
wherein the instructions include instructions for retrieving the second change data (Yin: ¶ 0057 the controller 220 and/or the device 201 receives booking change data from second client device 102; also see ¶ 0055-0057 generally as above)
Claim 5: Yin discloses claim 4, and further discloses:
wherein the second change data includes the second operational travel information change data and non-order change data (Yin: ¶ 0055-0058 showing booking change data may include both data corresponding to changes to be made to order data, i.e. operational travel data, and data which does not have a corresponding field in the order data and is not changed in the order data, i.e. non-order change data) and wherein modifying the secondary order comprises modifying the secondary order to include only the second operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
and not the non-order change data (Yin: ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”)
Claim 6: Yin discloses claim 1, and further discloses:
wherein the instructions include instructions for receiving the third change data (Yin: ¶ 0067 showing “the controller 220 and/or the device 201, in the legacy mode for the booking data: receiving, from the first client device 101, booking change data” at the OMS; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”)
Claim 7: Yin discloses claim 6, and further discloses:
wherein the third change data includes the third operational travel information change data and non-PNR change data (Yin: ¶ 0064-0066 showing booking change data may include both data corresponding to changes to be made to PNR/ticket data, i.e. operational travel change data, and data which does not have a corresponding field in the PNR/ticket data, i.e. non-PNR change data) and wherein communicating the third operational travel information change data to the airline PSS comprises communicating only the third operational travel information change data (Yin: ¶ 0064 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”)
and not the non-PNR change data (Yin: ¶ 0065-0066 showing booking change data that may “One exception to this example may be the OMS system 111 updating the corresponding order data at the first database 121 when the booking change data includes changes to the corresponding order data that will not otherwise impact the one or more of the passenger name record and the ticket data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the one or more of the passenger name record,” wherein the OMS 111 may update the corresponding order data according to the booking change data, but does not communicate the non-PNR change data)
Note: As per above, note that as in Yin in ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode.”
Claim 8: Yin discloses claim 1, and further discloses:
wherein the instructions include instructions for retrieving the fourth change data (Yin: ¶ 0057 the controller 220 and/or the device 201 receives booking change data from second client device 102; also see ¶ 0055-0057 generally as above)
Claim 9: Yin discloses claim 8, and further discloses:
wherein the fourth change data includes the fourth operational travel information change data and non-order change data (Yin: ¶ 0055-0058 showing booking change data may include both data corresponding to changes to be made to order data, i.e. operational travel data, and data which does not have a corresponding field in the order data and is not changed in the order data, i.e. non-order change data) and wherein modifying the primary order comprises modifying the primary order to include only the fourth operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
and not the non-order change data (Yin: ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”)
Note: As per above, note that as in Yin in ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode.”
Claim 10: See the rejection of claim 1 above disclosing the method of claim 1 by Yin. Yin further discloses: A method comprising executing the non-transitory computer readable medium of claim 1 (Yin: Fig. 3, ¶ 0041-0042, ¶ 0054-0057, ¶ 0066-0072, ¶ 0076-0078, ¶ 0085 showing methods; and ¶ 0104 showing “Persons skilled in the art will appreciate that in some examples, the functionality of devices and/or methods and/or processes described herein can be implemented using pre-programmed hardware or firmware elements (e.g., application specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), etc.), or other related components. In other examples, the functionality of the devices and/or methods and/or processes described herein can be achieved using a computing apparatus that has access to a code memory (not shown) which stores computer-readable program code for operation of the computing apparatus. The computer-readable program code could be stored on a computer readable storage medium …he computer-readable program can be stored as a computer program product comprising a computer usable medium. Further, a persistent storage device can comprise the computer readable program code. It is yet further appreciated that the computer-readable program code and/or computer usable medium can comprise a non-transitory computer-readable program code and/or non-transitory computer usable medium”).
Claim 11: Yin discloses:
A method (Yin: Fig. 3, ¶ 0041-0042, ¶ 0054-0057, ¶ 0066-0072, ¶ 0076-0078, ¶ 0085, ¶ 0104 showing methods for synchronizing travel booking data records) comprising:
receiving order data at an order management system (OrMS) (Yin: ¶ 0025, ¶ 0043-0045 showing receiving booking data, i.e. order data, by device 201 from a first client device; see ¶ 0078 specifying “the depicted first client device 101 generates booking data 401 and transmits the booking data 401 to the device 201 and/or the OMS 111, which receives the booking data 401 at the block 302”);
using the OrMS, generating a primary order from the order date [data] (Yin: ¶ 0049 and ¶ 0078-0079 showing after order management system (OMS 111) of device 201 receives booking data, the OMS generates order data, i.e. a primary order, which includes any suitable data associated with the booking data including, but not limited to, fields populated with product attributes and/or client attributes as described above, the fields populated according to the booking data; see ¶ 0029 further showing the generated order data include fields “such as product identifiers (e.g. service identifiers, item identifiers and the like), locations, dates and times corresponding to the products (e.g. flight times and other itinerary data). Other fields of the data object define client attributes, such as client identifiers (e.g. identifying the traveler, in the case of travel-related products such as the above-mentioned flights), payment data, and the like”);
extracting, via the OrMS, operational travel information from the order data (Yin: ¶ 0080 “To cause the legacy system 112 to generate a corresponding passenger name record at the second database 122, the device 201 and/or the OMS 111 transmits (e.g. at the block 310) a command 411 to the legacy system 112 which may include data from the booking data 401 and/or the order data 403 to be included in a corresponding passenger name record. The legacy system 112 (and/or the device 201) responsively generates a corresponding passenger name record (PNR) 413 (and/or or one or more PNRs) and stores the corresponding PNR 413 at the second database 122, for example in association with the booking identifier 405 (e.g. transmitted with the command 411)”);
using the OrMS, generating a secondary passenger name record (PNR) from the operational travel information (Yin: ¶ 0080 “To cause the legacy system 112 to generate a corresponding passenger name record at the second database 122, the device 201 and/or the OMS 111 transmits (e.g. at the block 310) a command 411 to the legacy system 112 which may include data from the booking data 401 and/or the order data 403 to be included in a corresponding passenger name record. The legacy system 112 (and/or the device 201) responsively generates a corresponding passenger name record (PNR) 413 (and/or or one or more PNRs) and stores the corresponding PNR 413 at the second database 122, for example in association with the booking identifier 405 (e.g. transmitted with the command 411)”);
using a bidirectional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”), communicating the secondary PNR to an airline passenger service system (PSS) (Yin: ¶ 0080 “the OMS 111 transmits (e.g. at the block 310) a command 411 to the legacy system 112 which may include data from the booking data 401 and/or the order data 403 to be included in a corresponding passenger name record”; and ¶ 0050 “the controller 220 and/or the device 201 may cause the OMS 111 to communicate with the legacy system 112 to cause the legacy system 112 to generate a passenger name record at the second database 122 that includes the same and/or similar data stored in the order data, for example in respective fields, but according to a second format (such as a GDS-based format, as described above), for example stored in association with the booking data and/or a booking identifier”; see ¶ 0022 showing “In some examples, the legacy system 112 comprises a PSS,” i.e. passenger service system as defined in ¶ 0015); and
(i) receiving, via the OrMS, first change data related to the primary order (Yin: ¶ 0053-0056, ¶ 0064-0066 showing the controller 220 of device 201 is configured to receive booking change data related to the from the first device at the order management system/device 201, i.e. change related to the primary order from the original booking data; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
using the OrMS, determining whether the first change data includes first operational travel information change data (Yin: ¶ 0064, ¶ 0089 showing that booking change data received at OMS may be identified as including changes to be reflected in the PNR and/or ticket data, i.e. operational travel change data, or otherwise in ¶ 0065 the booking change data may include change for which no corresponding field exists in the one or more of the passenger name record and the ticket data, i.e. non-PNR/non-operational travel change data);
modifying the primary order via the OrMS to include the first change (Yin: ¶ 0065 showing the change may be made only to the order information in the first database if the booking change data includes changes for which no corresponding field exists in the PNR/ticket data in the legacy system);
and if the first change data is determined to include the first operational travel information change data, using the bidirectional bridge, communicating the first operational travel information change data to the airline PSS (Yin: ¶ 0064, Fig. 5 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”; also see ¶ 0089); or
(ii) using the bidirectional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”; also see bidirectional bridge described in Fig. 5), retrieving second change data from the airline PSS to the OrMS (Yin: ¶ 0055-0056 showing the legacy system receives booking change data from a second device, i.e. a change related to the primary PNR, and redirects the booking change data to the OMS – “when a second client device 102 attempts to access and make changes to the booking data, for example by transmitting, to the legacy system 112, booking change data, the legacy system 112 may redirect such booking change data to the OMS 111”; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
using the OrMS, determining whether the second change data includes second operational travel information change data (Yin: ¶ 0055-0057 respectively showing identifying, based on the booking change data, that the booking change data should cause the order data to be changed at the first database, or otherwise, in ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”);
and if the second change data is determined to include the second operational travel information change data, modifying the primary order via the OrMS to include the second operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
Claim 12: Yin discloses claim 11, and further discloses:
comprising receiving the first change data (Yin: ¶ 0053-0056, ¶ 0064-0066 showing the controller 220 of device 201 is configured to receive booking change data)
Claim 13: Yin discloses claim 12, and further discloses:
wherein the first change data comprises first operational travel information change data and non-PNR data (Yin: ¶ 0064-0066 showing booking change data may include both data corresponding to changes to be made to PNR/ticket data, i.e. operational travel change data, and data which does not have a corresponding field in the PNR/ticket data, i.e. non-PNR change data) and wherein communicating the first operational travel information change data comprises communicating only the first operational travel information change data (Yin: ¶ 0064 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”; also see ¶ 0089)
and not the non-PNR change data (Yin: ¶ 0065-0066 showing booking change data that may “One exception to this example may be the OMS system 111 updating the corresponding order data at the first database 121 when the booking change data includes changes to the corresponding order data that will not otherwise impact the one or more of the passenger name record and the ticket data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the one or more of the passenger name record,” wherein the OMS 111 may update the corresponding order data according to the booking change data, but does not communicate the non-PNR change data)
Claim 14: Yin discloses claim 11, and further discloses:
retrieving the second change data (Yin: ¶ 0055-0056 showing the legacy system receives booking change data from a second device, i.e. a change related to the primary PNR, and redirects the booking change data to the OMS)
Claim 15: Yin discloses claim 14, and further discloses:
wherein the second change data includes the second operational travel information change data and non-order change data (Yin: ¶ 0055-0058 showing booking change data may include both data corresponding to changes to be made to order data, i.e. operational travel data, and data which does not have a corresponding field in the order data and is not changed in the order data, i.e. non-order change data) and wherein modifying the primary order comprises modifying the primary order to include only the second operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
and not the non-order change data (Yin: ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”)
Claim 16: Yin discloses:
A method (Yin: Fig. 3, ¶ 0041-0042, ¶ 0054-0057, ¶ 0066-0072, ¶ 0076-0078, ¶ 0085, ¶ 0104 showing methods for synchronizing travel booking data records) comprising:
using a bidirectional bridge providing communication between an order management system (OrMS) and an airline passenger service system (PSS) (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”; ¶ 0022 showing “In some examples, the legacy system 112 comprises a PSS,” i.e. passenger service system as defined in ¶ 0015), retrieving a primary passenger name record (PNR) created by the airline PSS (Yin: ¶ 0085-0086 showing if booking data is received from a second client device, the legacy system of device 201 generates a PNR and ticket data, and in ¶ 0087 “To cause the OMS 111 to generate corresponding order data at the first database 121, the device 201 and/or the legacy system 112 transmits (e.g. at the block 316) a command 611 to the OMS 111 which may include data from the booking data 601 and/or the PNR 603 and/or the ticket data 604 to be included in corresponding order data. The OMS 111 (and/or the device 201) responsively generates corresponding order data 613 and stores the corresponding order data 613 at the first database 121”);
using the OrMS, generating a secondary order from the primary PNR (Yin: ¶ 0087 “To cause the OMS 111 to generate corresponding order data at the first database 121, the device 201 and/or the legacy system 112 transmits (e.g. at the block 316) a command 611 to the OMS 111 which may include data from the booking data 601 and/or the PNR 603 and/or the ticket data 604 to be included in corresponding order data. The OMS 111 (and/or the device 201) responsively generates corresponding order data 613 and stores the corresponding order data 613 at the first database 121”); and
(i) using the bidirectional bridge (Yin: ¶ 0033 “the OMS 111 and the legacy system 112 are generally in communication via one or more communication links…the OMS 111 and the legacy system 112 may be configured to communicate with each other to exchange data, for example when generating and/or synchronizing data objects at the databases 121, 122”; also see bidirectional bridge described in Fig. 5), retrieving first change data from the airline PSS to the OrMS (Yin: ¶ 0055-0056 showing the legacy system receives booking change data from a second device, i.e. a change related to the primary PNR, and redirects the booking change data to the OMS – “when a second client device 102 attempts to access and make changes to the booking data, for example by transmitting, to the legacy system 112, booking change data, the legacy system 112 may redirect such booking change data to the OMS 111”; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
using the OrMS, determining whether the first change data includes first operational travel information change data (Yin: ¶ 0055-0057 respectively showing identifying, based on the booking change data, that the booking change data should cause the order data to be changed at the first database, or otherwise, in ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”);
and if the first change data is determined to include the first operational travel information change data, modifying the secondary order via the OrMS to include the first operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database); or
(ii) receiving, via the OrMS, second change data related to the secondary order (Yin: ¶ 0067 showing “the controller 220 and/or the device 201, in the legacy mode for the booking data: receiving, from the first client device 101, booking change data” at the OMS; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”);
using the OrMS, determining whether the second change data includes second operational travel information change data (Yin: ¶ 0067 showing that booking change data received at OMS may be identified as including changes to be reflected in the PNR and/or ticket data, i.e. operational travel change data, or otherwise in ¶ 0065 the booking change data may include change for which no corresponding field exists in the one or more of the passenger name record and the ticket data, i.e. non-PNR/non-operational travel data);
modifying the secondary order via the OrMS to include the second change (Yin: ¶ 0067 showing causing the corresponding order data to be changed at the first database 121 according to changes made to the one or more of the passenger name record and the ticket data at the second database 122);
and if the second change data is determined to include the second operational travel information change data, using the bidirectional bridge, communicating the second operational travel information change data to the airline PSS (Yin: ¶ 0066-0067 showing redirecting changes from the OMS to the legacy system, i.e. PSS, based on the booking change data; see ¶ 0033 showing bidirectional bridge for communications between the OMS and legacy system/PSS)
Claim 17: Yin discloses claim 16, and further discloses:
comprising retrieving the first change data (Yin: ¶ 0057 the controller 220 and/or the device 201 receives booking change data from second client device 102; also see ¶ 0055-0057 generally as above)
Claim 18: Yin discloses claim 17, and further discloses:
wherein the first change data includes the first operational travel information change data and non-order change data (Yin: ¶ 0055-0058 showing booking change data may include both data corresponding to changes to be made to order data, i.e. operational travel data, and data which does not have a corresponding field in the order data and is not changed in the order data, i.e. non-order change data) and wherein modifying the secondary order comprises modifying the secondary order to include only the first operational travel information change data (Yin: ¶ 0055-0057 as above showing based on the booking change data, redirected the booking changes from the legacy system to the OMS and making corresponding changes to the order data, i.e. the second order corresponding to the “second order” above, in the first database)
and not the non-order change data (Yin: ¶ 0058 “One exception to this example may be the legacy system 112 updating the corresponding passenger name record at the second database 122 when the booking change data includes changes to the corresponding passenger name record that will not otherwise impact the order data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the order data, but for which a corresponding field exists in the corresponding passenger name record. One example is a remark field in the corresponding passenger name record that indicates a “VIP PASSENGER” for which there is no corresponding field in the order data. In these example, the legacy system 112 may update the corresponding passenger name record according to the booking change data”)
Claim 19: Yin discloses claim 16, and further discloses:
comprising receiving the second change data (Yin: ¶ 0067 showing “the controller 220 and/or the device 201, in the legacy mode for the booking data: receiving, from the first client device 101, booking change data” at the OMS; note that as per ¶ 0071-0073 the mode of the booking change data may be switched according to the received booking change data and ¶ 0090 “it is understood that the depicted examples may occur concurrently, such that some booking data is in a first order mode (and/or another order mode), while other booking data is in a legacy mode. Indeed, the system 100 may include thousands, hundreds of thousands, millions, etc. of booking orders, and each may be in an associated order mode or an associated legacy mode”)
Claim 20: Yin discloses claim 19, and further discloses:
wherein the second change data comprises second operational travel information change data and non-PNR data (Yin: ¶ 0064-0066 showing booking change data may include both data corresponding to changes to be made to PNR/ticket data, i.e. operational travel change data, and data which does not have a corresponding field in the PNR/ticket data, i.e. non-PNR change data) and wherein communicating the second operational travel information change data comprises communicating only the second operational travel information change data (Yin: ¶ 0064 showing “when a first client device 101 attempts to access and make changes to the booking data, for example by transmitting, to the OMS system 111, booking change data, the OMS system 111 will redirect such booking change data to the legacy system 112, such that the legacy system 112 updates the one or more of the passenger name record and the ticket data according to the booking change data, and changes to the passenger name record and the ticket data occur at the corresponding order data when a synchronization occurs”)
and not the non-PNR change data (Yin: ¶ 0065-0066 showing booking change data that may “One exception to this example may be the OMS system 111 updating the corresponding order data at the first database 121 when the booking change data includes changes to the corresponding order data that will not otherwise impact the one or more of the passenger name record and the ticket data; for example, the booking change data may include addition of a product and/or a service for which no corresponding field exists in the one or more of the passenger name record,” wherein the OMS 111 may update the corresponding order data according to the booking change data, but does not communicate the non-PNR change data)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hunter Molnar whose telephone number is (571)272-8271. The examiner can normally be reached Monday - Friday, 7:30 - 4:00 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.
/HUNTER MOLNAR/Examiner, Art Unit 3628
Prosecution Insights