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 .
This Office action is in response to the amendments, arguments and remarks, filed on 1/6/2026, in which claim(s) 1, 3-10, 12-19 is/are presented for further examination.
Claim(s) 1, 4, 5, 7, 8, 10 and 12-19 has/have been amended.
Claim(s) 2, 11 and 20 has/have been cancelled.
Response to Amendment
Applicant’s amendment(s) to [0235] of the specification has/have been accepted.
Applicant’s amendment(s) to claim(s) 1, 10 and 19 has/have been accepted. The rejection(s) of the claim(s) under 35 U.S.C. 101, as being directed to an abstract idea without significantly more, has/have been withdrawn. Consequently, the rejection(s) of claim(s) 2-9, 11-18 and 20, which depend(s) from claim(s) 1, 10 and 19, has/have also been withdrawn.
Applicant’s amendment(s) to claim(s) 1, 4, 5, 7, 8, 10 and 12-19 has/have been accepted.
The examiner thanks applicant’s representative for pointing out where s/he believes there is support for the amendment(s).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 3-10, 12-19, filed on 1/6/2026, have been fully considered but they are not persuasive. Accordingly, this action has been made FINAL.
Applicant’s arguments with respect to the rejection(s) of claim(s) 1-20, under 35 U.S.C. 103, see pages 16-19 of applicant’s remarks, filed on 1/6/2026, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3-10, 12-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hed et al., US 2011/0055770 A1 (hereinafter “Hed”) in view of Torson, US 2020/0177695 A1 (hereinafter “Torson”) in further view of Karl et al., US 2021/0089550 A1 (hereinafter “Karl”).
Claims 1, 10 and 19
Hed discloses a method comprising:
maintaining, via one or more server computing devices (Hed, [0050], see data processing system in a client/server type environment; and Hed, [0055], see web server):
a travel event database storing a travel event data indicative of a given travel event (Hed, [0014], see the current system and method provides a user interface that may be adapted for use with a Reservation and Departure Control System (RDCS) for a transportation carrier such as an airline. The RDCS is used to re-accommodate passengers after a weather-related occurrence, an equipment change, or any other event that requires passengers to be moved from one accommodation (e.g., flight) to another by the transportation carrier; Hed, [0061], see RDCS 114 further includes a booking data module 202 [i.e., interpreted as the “travel event database”] that receives and manages the booking data associated with airline flights. Booking data is defined as all of the information about a passenger or a group of passengers traveling together on the same journey. Such information includes passenger names, the number of segments in the journey, the routes (which for an airline includes the flight numbers), and any special needs and requirements such as special meals, wheelchairs, etc. that may be needed by one of the members in the party. It may further include car rental and hotel information, the manner in which the passengers are being ticketed, data regarding travel documents, contact and payment information, and information regarding any other accommodation or service associated with the journey. For example, the system may store information indicating the customer is to receive flowers at his hotel room, that the customer has booked tickets for a show, that the customer requires limousine service, and etc.; and Hed, Fig. 2, see booking data module 202) represented by one or more provider objects (Hed, [0057], see one or more of these modules is implemented in object-based technology, where the respective airline data in the booking data module implemented in object-based technology would be the “respective provider objects”) and associated with a plurality of users (See Hed, [0061] above specifically booking data is defined as all of the information about a group of passengers [i.e., “plurality of users”] traveling together on the same journey [i.e., “given travel event”]; and Hed, [0099], see Login tab 410 for logging into the system [i.e., different logins for different users]), and
a shared travel event database storing a plurality of data data indicative of a respective travel event represented by a respective provider object provided by a travel provider system and associated with a respective individual user of the plurality of users (Hed, [0062], see customer profile data is managed by customer profile data module 204 [i.e., interpreted as the “shared travel event database”]. This module obtains and stores all information about a given customer, including customer preferences regarding seat assignments, meals, preferred connection points, connection points that are to be avoided, and a preferred maximum number of flight connections per journey, hotel and vehicle preferences, preferred methods of payment and so on. The information may further provide contact information, including the preferred modes of communication, special customer needs and requirements such as handicap needs or whether the traveler is an unaccompanied minor, and information regarding loyalty programs in which the customer participates such as frequent flier plans. Such information may include the ways in which a customer would like to be compensated in the event he is inconvenienced by the carrier and becomes eligible for some type of compensation program. History information may also be provided, including whether, and the manner in which, a customer has been inconvenienced by the carrier in the past. This information may be used to provide automatic upgrades and/or discounts the next time the customer books transportation; Hed, Fig. 2, see customer profile data module 204; and Hed, [0057], see one or more of these modules is implemented in object-based technology, where the respective airline data in the booking data module implemented in object-based technology would be the “respective provider objects”; Note: The claim has not defined what a travel event database or what a shared travel event database are in the claim. The term names are suggestive of what they are; however, the claim does not actually define the terms. The “travel event” and “shared travel event” are nonfunctional descriptive material),
comparing, via the one or more server computing devices, a given stored at the shared travel event database, with the travel event data stored at the travel event database to determine whether a respective travel event indicated by the given is associated with the given travel event manages all passenger-related activities that must be performed because a flight re-scheduling event makes it necessary to change original transportation plans. In particular, re-booking module 116 runs impact analyses to determine if schedule changes, flight equipment changes, delays, cancellations, misconnects, or any other type of irregular occurrence will affect customer bookings, check-in, seat assignments, baggage, travel documents, and/or travel plans. The system further manages the activities required to re-accommodate all affected customer bookings, including the re-adjustment of inventories, seat re-assignments, the updating of applicable travel documents and customer and flight information, and the generating of messages to provide adequate notifications, where the flight information in the booking data module and the customer profile data module are compared and updated with any changes to applicable flights);
in response to determining that the respective travel event indicated by the given is associated with the given travel event indicated by the travel event data
synchronizing, via the one or more server computing devices, the travel event database and the shared travel event database by adding to the travel event data
to generate a graphic user interface at a display screen showing respective portions (Hed, [0096], see user interface logic 301 and user interface modules 222 are designed to provide screens that visually convey to a user the overall flow of the re-booking process and the structure that makes up a RAID. Recall that a RAID is a construct created to track the re-booking activity described above. The screens provided by user interface logic 301 and user interface modules 222 are further designed to guide the user through completing or interacting with the process by linking screens and tasks in a manner that corresponds to the way in which they would most typically be used. Additional navigational links are provided to allow a user to quickly locate and enter information without having to navigate to unnecessary and unrelated screens)
Hed does not appear to explicitly disclose containers;
shareable containers;
wherein each shareable data container includes an indication identifying at least a portion of the shareable data container as being shareable;
adding a pointer to the given shareable data container, wherein the data container aggregates pointers to multiple shareable data containers associated with the given event while maintaining the multiple shareable data containers as distinct, user-associated data records; and
when the travel event data container is processed:
identifying the pointers to multiple shareable data containers;
retrieving the multiple shareable data containers; and
processing the multiple shareable data containers of the multiple shareable data containers indicated as being shareable.
Torson discloses containers (Torson, [0046], see the consumer group polling queues 214a-214c are configured to allow any number of consumer groups 220 (e.g., cache consumers) to receive data from a container maintained in the shard data container 210. In some embodiments, the shard 120a-120c is configured to receive an event from the data pipeline 202 and determine whether the container in the shard data container 210 is set to be consumed (e.g., is in a group queue)).
Hed and Torson are analogous art because they are from the same field of endeavor, such as managing data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Hed and Torson before him/her, to modify the event database of Hed to include the containers of Torson because it allows processing of a lot of data.
The suggestion/motivation for doing so would have been to prevent a continuously increasing backlog of events to be processed, see Torson, [0003].
Therefore, it would have been obvious to combine Torson with Hed to obtain the invention as specified in the instant claim(s).
The combination of Hed and Torson does not appear to explicitly disclose shareable;
wherein each shareable data includes an indication identifying at least a portion of the shareable data as being shareable;
adding a pointer to the given shareable data, wherein the data aggregates pointers to multiple shareable data associated with the given event while maintaining the multiple shareable data as distinct, user-associated data records; and
when the travel event data is processed:
identifying the pointers to multiple shareable data;
retrieving the multiple shareable data; and
processing the multiple shareable data of the multiple shareable data indicated as being shareable.
Karl discloses shareable (Karl, [0093], see a virtual table schema 718 can specify whether the replica table 738 should be shared. If the replica table 738 is designated as shareable, the scenario of FIG. 7 can result. If the replica table 738 is designated as non-shareable, the replica table is only available to the schema 714 which requested the change to a replica table. The remaining schemas 718 reference the remote table 730, until and unless they request to create another replica table in the data store 742 (in which case there can be multiple replica tables of the same remote table 730 in the data store) or the schema 714 that requested the creation of the replica table 738 changes the status of the replica table to shareable);
wherein each shareable data includes an indication identifying at least a portion of the shareable data as being shareable (See Karl, [0093] above where the portion shareable is the entire table);
adding a pointer to the given shareable data, wherein the data aggregates pointers to multiple shareable data associated with the given event while maintaining the multiple shareable data as distinct, user-associated data records (Karl, [0006], see a virtual table schema includes a logical pointer that is used to target a table that includes data and is defined according to the virtual table schema. Values assigned to the logical pointer can be used to target tables at different locations, such as in a federated database system [i.e., logical pointer points to data in different locations/multiple shareable data in the federated database system and the data is maintained at the different locations in the federated database system, which discloses “maintaining the multiple shareable data as distinct, user-associated data records”] or in a cache of a database management system of a central computing system. When data associated with the virtual table is requested, or prior to the request being received, the data can be stored in a table in the cache. The logical pointer can be updated to reference the cache. If the cache is full, the table can be removed from the cache, and the logical pointer can be updated to reference a table at the federated database system; Karl, [0007], see updating a logical pointer for a virtual table schema. A first schema is created in a data dictionary for a first virtual table. The first schema includes a first logical pointer specifying a first location of a first table having first data [i.e., pointer to a first shareable data] and defined according to the first schema. The first location is in a first federated database system; and Karl, [0008], see at least a portion of the first data is received. A second table is created in a cache of a central computing system hosting a database management system. The second table is defined according to the first schema. The received at least a portion of the first data is stored in the second table. A second value is assigned to the first logical pointer. The second value identifies a location in the cache of the second table [i.e., pointer to a second shareable data]); and
when the travel event data is processed:
identifying the pointers to multiple shareable data (Karl, [0054], see virtual table schemas 160 can be associated with a table pointer 162 and optionally with status information 164. The table pointer 162 can be a logical pointer used to identify what table should be accessed for data of the corresponding virtual table schema 160. For example, depending on the state of the table pointer 162, the table pointer can point to the remote table 144 of a remote database system 112 or a replica table 166 (which can be generated from the remote table 144) located in a data store 168 of the central computing system 110. The data store 168 can also store data for local tables 170, which can be defined by the local table schemas 136; and Karl, [0093] above disclosing tables as shareable/non-shareable);
retrieving the multiple shareable data (Karl, [0054] above for the pointers identifying what and where table should be accessed for data); and
processing the multiple shareable data of the multiple shareable data indicated as being shareable (Karl, [0054] above for the pointers identifying what and where table should be accessed for data; Karl, [0058], see, when a query is executed, the query is processed by the query processor 120, including executing the query using the query executor 124 to obtain data from one or both of the data store 142 of the remote database system 112 or the data store 168 of the central computing system 110. Query results can be returned to the application 108. Query results can also be cached, such as in a cache 178 of the central computing system 110. The cached results can be represented as cached views 180 (e.g., materialized query results); and Karl, [0093] above disclosing tables as shareable/non-shareable).
Hed, Torson and Karl are analogous art because they are from the same field of endeavor, such as managing data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Hed, Torson and Karl before him/her, to modify the event database with containers of the combination of Hed and Torson to include the shareable data pointers of Karl because it allows the sharing of data without first downloading the data.
The suggestion/motivation for doing so would have been to reduce the time and resources needed for processing, see Karl, [0003].
Therefore, it would have been obvious to combine Karl with the combination of Hed and Torson to obtain the invention as specified in the instant claim(s).
Claim(s) 10 and 19 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale.
With respect to claim 10, Hed discloses a server computing device comprising:
a communication interface (Hed, [0055], see the network-based interface); and
a controller (Hed, [0049], see instruction processors).
With respect to claim 19, Hed discloses a non-transitory computer-readable medium storing a computer program (Hed, [0050], see memory).
Claims 3 and 12
With respect to claims 3 and 12, the combination of Hed, Torson and Karl discloses wherein the travel event data container is further indicative of a plurality of sub-travel events that are components of the given travel event, the method further comprising:
analyzing the travel event data container to identify a given sub-travel event of the given travel event (See below);
generating a group of users associated with the given sub-event (Hed, [0061], see specifically booking data is defined as all of the information about a group of passengers [i.e., “plurality of users”] traveling together on the same journey);
determining that a change to the given sub-travel event has occurred (Hed, [0015]-[0016], see the RDCS that may be employed within the airlines industry, when passengers must be re-booked from one flight to another, RDCS 114 creates a Re-Booking Activity IDentifier (RAID). This RAID is a data structure that contains information about the re-accommodation activity, including an identification of the one or more original flights that must be re-accommodated. After a RAID is created, a guide is generated for the RAID. The guide lists all of the possible flights that may be used to re-accommodate the passengers that were originally scheduled to travel on the flight(s) associated with the RAID. After a guide is generated, all of the passengers affected by the cancelled flights must be re-accommodated. In one embodiment, the system applies a set of business rules that will select from among the flights in the guide to obtain the flight that best re-accommodates each of the passengers. The flight selected to re-accommodate one passenger is not necessarily the same flight selected for a different passenger. The flights are selected based on passenger requirements, preferences, and other factors associated with the passenger's original booking, where the re-bookings of a passenger on individual flights are the “given sub-events”; and Torson, [0014]); and
in response to determining that the change to the given sub-travel event has occurred, providing a message to network addresses of the group of users, indicating the change to the given sub-travel event (Hed, [0091], see the passengers associated with the bookings are also notified of the re-accommodations. Notification rules 340 define the process that will be used to notify each passenger, using email addresses [i.e., “network addresses”]; and Torson, [0014]).
Claims 4 and 13
With respect to claims 4 and 13, the combination of Hed, Torson and Karl discloses wherein the travel event data container is further indicative of a plurality of sub-travel events that are components of the given travel event, the method further comprising:
receiving, from a travel event management device, a request to join a given sub-travel event at the travel event data container, the request associated with a given user of the plurality of users (Hed, [0087], see an attempt will be made to re-book each of the bookings affected by the event on the one of the flights in the guide that best satisfies the requirements of that particular booking; Hed, [0099], see Login tab 410 for logging into the system [i.e., different logins for different users]; Torson, [0014]; and Torson, [0038], see joining events);
one or more of:
comparing the request with at least one given rule (Hed, [0086], see, after all candidate flights that are selected by the flight availability rules are added to the guide, the flights may be ordered according to programmable criteria selected by flight availability rules); and
requesting approval of the request (Hed, [0087], where actually being able to re-book means there was an approval request sent and approved; Hed, [0091], see, after all affected bookings have been re-accommodated, and if necessary, approved by an airline agent; and Torson, [0004], see confirmation and updating); and
when one or more of the request meets the at least one given rule and the request is approved:
synchronizing the travel event database and the shared travel event database by adding data indicative of the given sub-travel event to a respective shareable data container associated with the given user and to the travel event data container (Hed, [0091], see, after all affected bookings have been re-accommodated, and if necessary, approved by an airline agent, the results are provided as re-booking data 342 to booking data module 202 for storage in database 108; and Torson, [0004], see confirmation and updating).
Claims 5 and 14
With respect to claims 5 and 14, the combination of Hed, Torson and Hed discloses further comprising:
determining that one or more further respective travel events indicated by one or more respective further shareable data containers are associated with the given travel event indicated by the travel event data container, the one or more further respective travel events associated with further respective individual users (See below); and
synchronizing at least a further portion of the travel event database and the shared travel event database by adding respective pointers to the one or more respective further shareable data containers to the travel event data container (Hed, [0091], see, after all affected bookings have been re-accommodated, and if necessary, approved by an airline agent, the results are provided as re-booking data 342 to booking data module 202 for storage in database 108; Torson, [0004], see confirmation and updating; and Karl, [0006], see a virtual table schema includes a logical pointer that is used to target a table that includes data and is defined according to the virtual table schema. Values assigned to the logical pointer can be used to target tables at different locations, such as in a federated database system [i.e., logical pointer points to data in different locations/multiple shareable data in the federated database system and the data is maintained at the different locations in the federated database system, which discloses “maintaining the multiple shareable data as distinct, user-associated data records”] or in a cache of a database management system of a central computing system. When data associated with the virtual table is requested, or prior to the request being received, the data can be stored in a table in the cache. The logical pointer can be updated to reference the cache. If the cache is full, the table can be removed from the cache, and the logical pointer can be updated to reference a table at the federated database system; Karl, [0007], see updating a logical pointer for a virtual table schema. A first schema is created in a data dictionary for a first virtual table. The first schema includes a first logical pointer specifying a first location of a first table having first data [i.e., pointer to a first shareable data] and defined according to the first schema. The first location is in a first federated database system).
Claims 6 and 15
With respect to claims 6 and 15, the combination of Hed, Torson and Karl discloses further comprising:
requesting, via a network address of a respective given user associated with the travel event data container, approval of one or more of:
the respective travel event and at least one of the one or more further respective travel events (See below);
in response to receiving the approval, updating the travel event data container to indicate the approval (See below); and
in response to receiving a denial of the approval, providing a notification of the denial to a travel event management device to cancel one or more of:
the respective travel event and at least one of the one or more further respective travel events (Hed, [0091], see the passengers associated with the bookings are also notified of the re-accommodations. Notification rules 340 define the process that will be used to notify each passenger, using email addresses [i.e., “network addresses”]; Hed, [0154], see whether the booking has been successfully re-booked, and whether the one or more passengers associated with the booking have confirmed the rebooking; Hed, [0052] above where the flight information in the booking data module and the customer profile data module are compared and updated with any changes to applicable flights; and Torson, [0054], see removing containers).
Claims 7 and 16
With respect to claims 7 and 16, the combination of Hed, Torson and Karl discloses wherein the travel event data container comprises at least a portion of the given shareable data container and at least a respective portion of a further shareable data container associated with the given travel event, the method further comprising:
analyzing respective data from the given shareable data container and the further shareable data container stored at the travel event data container to determine threshold-based inconsistencies therebetween (See below);
providing, to network addresses of respective users associated with the given shareable data container and the further shareable data container, respective links to a travel event management device that resolve the threshold-based inconsistencies (See below);
receiving, from the travel event management device, further data indicative of updated respective travel events associated with the respective users, the further data resolving the inconsistencies (See below); and
updating the travel event data container and one or more of the given shareable data container and the further shareable data container, based on the further data (Hed, [0091], see the passengers associated with the bookings are also notified of the re-accommodations. Notification rules 340 define the process that will be used to notify each passenger, using email addresses [i.e., “network addresses”]; Hed, [0098], see screen displayed with rebooking information; Hed, [0086], see the agent may delete flights; Hed, [0089], see cancelling original booking; Hed, [0052] above where the flight information in the booking data module and the customer profile data module are compared and updated with any changes to applicable flights; and Torson, [0004], see confirmation and updating).
Claims 8 and 17
With respect to claims 8 and 17, the combination of Hed, Torson and Karl discloses further comprising:
generating the travel event data container when at least two given shareable data containers stored in the shared travel event database share common data (Hed, [0014], see the current system and method provides a user interface that may be adapted for use with a Reservation and Departure Control System (RDCS) for a transportation carrier such as an airline. The RDCS is used to re-accommodate passengers after a weather-related occurrence, an equipment change, or any other event that requires passengers to be moved from one accommodation (e.g., flight) to another by the transportation carrier; and Torson, [0014], see receiving events and creating containers for them).
Claims 9 and 18
With respect to claims 9 and 18, the combination of Hed, Torson and Karl discloses further comprising:
generating the travel event data container (Hed, [0014], see the current system and method provides a user interface that may be adapted for use with a Reservation and Departure Control System (RDCS) for a transportation carrier such as an airline. The RDCS is used to re-accommodate passengers after a weather-related occurrence, an equipment change, or any other event that requires passengers to be moved from one accommodation (e.g., flight) to another by the transportation carrier) based on a request from one or more of:
a communication device (Hed, [0050], see dumb terminals, personal computers, hand-held devices such as Personal Data Assistants (PDAs), workstations, sound or touch activated devices, cursor control devices such as mice, printers, or any other known device used to provide data to, or receive data from, the data processing system; and Torson, [0021] and [0022], see communications hardware);
a travel event management device (Torson, [0040], see incoming events); and
a messaging application.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
– Philipeit, 2011/0213857 for process-oriented acquisition, storage, transmission and provision of data;
– Karl et al., US 2021/0089540 for virtual database tables with updatable logical table pointers;
– Goldman, 5963982 for defragmentation of stored data without pointer indirection;
– Zaveskey et al., 11379615 for event-based community creation for data sharing platform;
– Ghosh et al., 9946724 for scalable post-process deduplication;
– Weissman, 2014/0337064 for NoSQL online analytical processing architecture; and
– Bellers et al., EP 2743869 for an event management system.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Point of Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P 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, Neveen Abel-Jalil can be reached at (571) 270-0474. 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.
HUBERT G. CHEUNG
Assistant Examiner
Art Unit 2152
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2152Date: March 14, 2026
/NEVEEN ABEL JALIL/Supervisory Patent Examiner, Art Unit 2152